Environment versions
Network:
Windows 2008 Server
>>>>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".
This is like to check a LOCK record status to LOCK the record, it is useless;
are you sure the lock only after you have acquired it.
However, anyone is free to write programs that run in 99.99% of cases;
prefers me, if possible, 100%.
Previous
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only