This query is similar to one I posted a few months back so please bear with me.
I am a software developer creating applications using VB with VS2008. I have a customer who has several WAP3 devices running Win Mob 6.1 Professional. Also used is the Psion sdk V5.3. The devices collect data in batch mode, are placed in a 4 bay ethernet connected cradle and then using SQL commands directly update a SQL database running under SQL Express 2008 on a VM server running Windows Server 2000. The software on the WAP3 uses the standard SQL client (sql.ppc.wce5.armv4i.cab) installed manually.
The system has been running well for many weeks but suddenly I am getting errors at the start of the data update process. Error messages are saying that the device is unable to connect to the SQL server. When the device is in the cradle it is possible to ping the device from another PC on the network. It is not possible to ping the server from the device because, in their wisdom, Microsoft have removed the ping facility from the latest version of Win Mobile. The device is indicating that it has an IP address and the networking guys on site have done a remote desktop from the device to the SQL server. They insist therefore that there are no network issues. Now I am very aware that the cradle is actually 4 x usb to ethernet converters each with its own MAC address so, using DHCP, the IP address is allocated to the specific dock in the cradle and not directly to the device. If you move a device from one dock to another it gets a different IP address. I do not know if there are any implications of this. I think I am correct in saying that all network settings on the WAP3 are default.
When we get this error other devices in the same or different docks in the cradle work correctly. I have even run VS2008 on my laptop in diagnostic mode, connected to the device VIA ETHERNET (not usb!) when the error occurs. Does this prove the integrity of the network?
No matter what we attempt, and I have had much help from the on site networking guys, we cannot get the device to see the SQL server. However, for no obvious reason at all, it starts working again. Typically this is the next day but I cannot be more specific on timescales. Also if I remove the unit from the customer site and bring it back to my office 'duplicate installation' it works right away but again I am unsure of any timing implications.
This has not happened to all units on site, but perhaps 3 or 4.
Every failure is at the same place when the software initiates the SQL connection but that is always the first task when the unit is placed in the cradle.
Is this hardware (WAP3, cradle, usb-ethenet converter), is it network?, is it software? is it SQL client? is it SQL server? Is there a timing issue?
Any assistance appreciated!
Apologies for the length of this query.
Good evening Richard,
richardkm It is not possible to ping the server from the device because, in their wisdom, Microsoft have removed the ping facility from the latest version of Win Mobile.
It is not possible to ping the server from the device because, in their wisdom, Microsoft have removed the ping facility from the latest version of Win Mobile.
Thanks Jaques.I have downloaded that and tried it. It will certainly be a useful tool.
Richard
Hi Richard.
Sorry to hear your issue is not clearing up. Ping will help if the SQL server is configured to accept pings from outlying devices (Easily checked) but this may not be the whole problem.
For the SQL client I have two questions:
1) How are you authenticating the WAP3 / WM6.1 device to SQL server? Windows Authentication, or Generic SQL Server user authentication?
2)How are you adressing the SQL server over the network? TCP/IP DNS fqdn? {Fully Qualified Domain Name} Or WINS naming?
I usually suggest with SQL client to do the following: 1) Use SQL Server authentication to a Generic UserID/Password. 2) Use DNS fqdn names, or HOST name equivelents as backup.
WINS, and WINAUTH both are types of methods I find problematic on Windows Mobile devices. Consider the devices closer to non-windows type devices in development, and issues tend to be better managed.
As I had indicated before, the SCU supplicant has some diagnostics built in, the same cannot be said for the Wired connections. (Thanks Jacques.) So the Ping may help. But there may be more to this than meets the eye. -sean
Sean M. Kennedy {Americas Help Desk Application Support}
Hi Sean
Many thanks for the reply.
To answer your queries.
Authentication is by SQL authentication. The server is set up for both Win and SQL but the devices user SQL authentication. Same generic user ID and password for all devices.
We are addressing the server by specifying an IP address with the name of the SQL server instance in the SQL connection string.
I have downloaded the Ping and it is a useful tool but as you say it looks like the problem goes beyond this.
In the information I provided earlier I was wrong in saying it was Win Mob 6.1 Prof. It is actually Classic. Not sure if this makes any difference!
I am beginning to think I should double check versions of SQL clients etc. No real reason for doing this as I suspect that these clients have been stable for quite a long time. Maybe I am now just grabbing at straws.
Since the last occurance a couple of days ago the system has processed approx 2000 transactions without any issues!
Any further ideas?
Cheers
Thanks for that Richard.
WM6.1 PRO vs. CLA would be of concern if this was a WWAN driven issue. But since you are using the Cradle Ethernet for this, I suspect that you may find out more from the networking config which is mostly the same.
If anything I suggest testing with the cradle on the network as close to the SQL Server / DHCP Service as manageable when this occurs and you are troubleshooting. I suggest checking the TCP/IP address that gets assigned to the device to confirm it is valid on the network. As well do a self ping, and a ping to the Gateway as well, to check LAN connectivity.
Your SQL clients just need to be the same, and the .NET CF settings need to be consistent.
The SQL Client -- you know how to manage. For the .NET CF check, the utility called "\windows\cgacutil.exe" will show you the .NET CF versions on the WAP3's you are using. These should be consistent.
Since it is intermittent, I am beginning to wonder if the client has Rouge Static TCP/IP addresses set on devices that get connected occasionally, and causing a TCP/IP addressing conflict. -sean
Thanks Sean.
I do not know what a 'Rouge Static TCP/IP' address is?
Can you explain?
Richard.
Yes, My typical example is a Laptop device used to configure something on a network that has a Static TCP/IP address assigned (by a non-IT person) that directly interferes with an existing DHCP TCP/IP address that has been assigned. -sean
I understand but I think this is extremely unlikely and I know the IT guys on site will dismiss it. However I will ask the question next week.
Going back to your previous queries we have discussed the possibility of making the cradle much 'closer' to the server by installing the server on a local PC right next to the cradle. This is possible but would need some down time on the part of the devices and it probably would be up to me to do this. It would take a bit of time and I am a bit short of that commodity at the moment!
We have checked the IP assigned to the device/cradle and it is quite valid on the network. We can also ping this from several other PCs on the network. I have not pinged the gateway but am fairly sure the network guys have done this. I can check next week as well as run the 'Pocket PC ping' utility I downloaded earlier.
I am really coming round to the thought that it is a SQL issue rather than a network issue. Can we really se[parate these? SQL uses port 1433 by default. I have checked (via remote desktop to the server) and in SQL server this is all set to default but I am unsure about any firewalls.
I feel we are going round in circles at the moment!
I think you have enough (Round Table) information to assist you in your troubleshooting. So long as the network segment that the device/cradle is on the same network subnet segment as the SQL server and no routing is involved, then I would look at the SQL server. If the route to the SQL server is across a gateway boundary then you need to ping the gateways in between, and make sure that they know what to do for SQL Traffic.
-sean
Thanks Sean
Quite a few things to look at next week.
Any thoughts on possible SQL Client issues?
Was back on site today. All units have been working perfectly via the ethernet cradle for several days.
Today I installed the 'pocket PC ping' tool and also a small diagnostic tool I wrote.
However something very interesting did happen! Although operating in batch mode it is planned to go to wireless as soon as possible. The application is already set up for wireless comms and has been tested extensively off site. Today I set up 3 of the units to use wireless. After getting a wireless connection, as an experiment, I put one of them in to the 4 bay cradle with the ethenet connection. Then took it out of the cradle and it would not see the SQL server. The pocket pc ping worked and I could ping the server via wireless. I then ran my diagnostic tool (also wireless) which logs errors to a text file. This tool could not see the SQL server either and the results are at the bottom of this message. (Can I send the text file to you as an attachment as it does not display well here with no formatting!)
This looks like it is getting to be a SQL server/client problem rather than a network type issue or is it a driver issue.
Any thoughts?
======================== Opening SQL Connection Unable to open main server database Unable to open main server database Connection string=Data Source=166.1.11.14\SQLEXPRESS2;Initial Catalog=SEH_Wafer_Stock;User ID=kmpda1;Password=XXXXXXXX message=Specified SQL server not found: 166.1.11.14\SQLEXPRESS2 class="20" linenumber=0 number=6 procedure=ConnectionOpen (Connect()). server=166.1.11.14\SQLEXPRESS2 source=.Net SqlClient Data Provider state=0 InnerException=nothing StackTrace= at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, TdsParserState state) at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, TdsParserState state) at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning() at System.Data.SqlClient.TdsParser.Connect(String host, SqlInternalConnection connHandler, Int32 timeout) at System.Data.SqlClient.SqlInternalConnection.OpenAndLogin() at System.Data.SqlClient.SqlInternalConnection..ctor(SqlConnection connection, Hashtable connectionOptions) at System.Data.SqlClient.SqlConnection.Open() at SEH_PDA_Diagnostics.Form1.btnStart_Click(Object sender, EventArgs e) at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnClick(EventArgs e) at System.Windows.Forms.ButtonBase.WnProc(WM wm, Int32 wParam, Int32 lParam) at System.Windows.Forms.Control._InternalWnProc(WM wm, Int32 wParam, Int32 lParam) at Microsoft.AGL.Forms.EVL.EnterMainLoop(IntPtr hwnMain) at System.Windows.Forms.Application.Run(Form fm) at SEH_PDA_Diagnostics.Form1.Main()
The error log formatting is fine. It is what I expect. The unit was cradled, and was connected, then you removed it from the cradle and did not recycle the driver connection. Unless the network stack is recycled then the route to host ip may still be dirty. Networking wise, I suspect on the Wireless network, SQL Server connections traverse a different route to the SQL Server TCP/IP than the wired network does. In order to clear this up, the radio for Wifi may need to be shutdown in order to clear the network route list when the unit is removed from the quad dock.
A faster way may be to dispose of the SQL connection. Then retry connecting to the SQL connection, but on Windows Mobile this is hit and miss. Your Ping app being sucessful even though the SQL app was not leads me to that conclusion.
What happens when you shut-down the app (Full exit, confirmed from Task Manager) and restart the application? And reconnect? Did you get a chance to test that condition when you were onsite?
For the first attempt at wireless connection I did not recycle anything. However after that failure I did shut down the app and checked it in task manager. Also did a warm boot and the problem was still there. I am not fully sure how much a warm boot achieves though. Would this actually shut down the radio? Does 'disable' in SCU shut it down?
That is actually very good information. Which lead me to conclude that the connection between the Wireless network, and the SQL server is firewalling the Port 1433 / Ports 1025/1050 between the devices and the SQL server.
Wired works, so the client on the device is working 'Nuff Said. It is the route to the SQL and the port exposure for the SQL that is missing from the WiFi network.
The warm boot is the confirmation that it is not TCP/IP routing. When using WiFi, the SQL server is not accessable. That is my conclusion from your given information.
You can quickly confirm by demonstrating the same client app connecting wirelessly to a portable SSID / AP connected to your laptop in a Wireless Micronet. (Like a Linksys WRT54G and your laptop with no outside networking, and the AP connecting the WAP via 802.11b networking, and the linksys acting as the router and DHCP server.)
The laptop in this case would be the SQLExpress instance that you should be able to connect to.
I hope this helps.
Just a bit of an update.
All day today 2 units have been working successfully by wireless. I completely BANNED them from ever putting these units in the 4 bay cradle thereby preventing and IP connection via the wired network. there have been a couple of wireless issues but I do not think these are connected in any way. Not sure as I have not been on site, only know what I have been told on the phone - and that was not particulary clear!
I understand port 1433 is the default port for SQL server but why ports 1025/1050?