Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Wireless support for VFP9 app
Message
From
20/11/2011 05:36:30
 
 
To
19/11/2011 23:57:13
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
General information
Forum:
Visual FoxPro
Category:
Client/server
Environment versions
Visual FoxPro:
VFP 9 SP2
OS:
Windows Server 2008
Network:
Windows 2008 Server
Database:
MS SQL Server
Application:
Desktop
Miscellaneous
Thread ID:
01528963
Message ID:
01529303
Views:
49
>>>>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
Map
View

Click here to load this message in the networking platform