Pocket PC connection to SQL Server

  • Thread starter Thread starter adds21
  • Start date Start date
A

adds21

Hello,

I'm writing a PPC application which needs to connect to an instance of SQL
Server if the connection is available.

I can check that the PPC has network access by using the CFNET IPAddress
class, and I could even check the PPC can see a web server by using
HttpWebRequest or something, however I can't find a way to check to see if
the IP Address/machine name I specify in my server connection string is
actually available or not.

I was hoping that I could simply set the timeout in the connection string,
but that doesn't appear to have any effect, and the PPC simply hangs when it
tries to do a SQLConnection.Open if the IP address is non-accessible
(although it correctly accesses it if the server is found).

The problem is, that I can't rely on the fact the PPC is connected to a
network, or can see a web site. It's possible the SQL Server it's going to
try to connect to is in a private (10.x.x.x) network, and if the user moves
between wi-fi hotspots, they'll only be able to connect to the server if
they're connected to the correct network.

A "ping", while not ideal, would at least be one solution. Or I could try
to manually open a Socket to SQL, just to see if it works? Any ideas?

Thanks,
A.
 
Adds,

I'm not sure if this will specifically address your question, but since
it sounds like the SQL server is located remotely....have you
considered encapsulating the SQL access from inside a webservice? If
you wrote a web service that would encapsulate all of the database
calls, you would have a more flexible design and may be able to handle
errors better. It sounds like you already have a technique to verify
connectivity to a webserver, so that part is taken care of. Once
inside the web service, if the database connection was temporarily
unavailable then your web service could return a SoapException that
explained the problem.

Just an idea.

--steve
 
I'm not sure if this will specifically address your question, but since
it sounds like the SQL server is located remotely....have you
considered encapsulating the SQL access from inside a webservice?
Click to expand...

Hi Steve,

Yes, that is something I've given thought to. I may well end up having to
go down that route, as some of the information I've found since my original
post appear to indicate that the timeout for sockets on PDAs is set within
the BIOS, and cannot be changed. However I'm currently playing with
HttpWebRequest to see if I can get that to work with timeouts.

The problem with SOAP is that I'd like to (if possible) avoid the user
having to install anything extra (eg, IIS) on their server. We currently
have a userbase for our desktop application who already have a SQL Server
installed, so ideally I'd like to connect directly to the existing server
without the need to install or configure additional software.

That said though, I certainly agree that SOAP would be a neater (and
possibly the only) solution!

Regards,
A.
 
The problem is, that I can't rely on the fact the PPC is connected to a
network, or can see a web site.
Click to expand...

Okay, I think I've found a way around this problem in case anyone else has a
similar issue (I've seen quite a few posts about it around).

I'm using HttpWebRequest to look for the server, and to see if there is
anything on port 1433 (the SQL port). The "timeout" in HttpWebRequest
appears to work better than the timeout in SqlConnection. If HttpWebRequest
errors out with a WebExceptionStatus.ReceiveFailure, then I assume that
means there is *something* on port 1433, which is probably SQL Server.

Once I've found that out, I can then try to do a SqlConnection connect to
make sure it really is SQL Server (and the one I'm expecting to see). That
means that it only times out for an unspecified long period of time if I'm
unlucky enough to find a server with something other than SQL listening on
1433.

Wrapping all the above up in a thread means that I can run all the above in
the background while the user is doing something else, and simply let them
know if and when the SQL Server comes on-line (or in range).

All works pretty well.

Cheers,
A.
 
Back
Top