>>>Personally I prefer to establish connections on demand which helps a great deal.
>>>
>>>This may not be practical in situations where your application is rapidly firing off queries or commands that can't be neatly grouped into a batch (where you connect before and disconnect afterward). In that case, it is helpful to wrap the SQLEXEC command in a class that checks the connection state before sending the command. Sending simple command like Select GetDate() will reveal if the connection is functional. If not, reconnect.
>>
>>Actually, the simplest one I know of is
>>
>>sqlexec(h, "")
>
>It is useless.
>You can lose the connection after a ns result SQLEXEC (h, "").
>
>The only way it is to send the true command and check the result.

Not quite useless, just not 100% fullproof. You use this before you want to run something on a server from a workstation. The time since the last run can be minutes - the user was entering data for some time and now wants to save, or was doing something else and wants to look something up. The probability of a disconnect may be considered constant over time, so it could have happened at any time between the last operation and now; the longer the time, the higher the chance that it disconnected meanwhile.

Then you run a dummy command like this, reconnect if needed, and the next millisecond you're running a real SQL request. The probability of a disconnect during that millisecond is minuscule. Sure, shit happens and it can happen during that millisecond, but it's highly unlikely. And it's easier to have this check in oSomething.Handle_Access() than in every place where you use the handle.

Of course, you need to check the return from any call - but that wasn't the point of this exercise. This being about the wireless, the question was "how do I know whether I'm connected before I try anything".