>>>Hi all
>>>
>>>I have a VFP9 app that my client need to run on a wireless LAN
>>>
>>>Occasionally, when the connection is temporarily broken, it will crash my VFP9 app due to invalid database connection handle
>>>
>>>Is there a way for me to program a automatic reconnect should the connection handle be invalid from a temporary broken network connection?
>>
>>1. You could re-architect your app so it only holds VFP data files open for the minimum amount of time, and closes them when finished. However, this will not help if the connection loss means you lose your logon to the remote server. Also it will not help if you lose the connection in the middle of a data update operation. In short, accessing VFP data files across a wireless LAN is a bad idea and will cause problems sooner or later.
>>
>>2. You could set up a Terminal Server and run the VFP app exclusively on that. Clients then log in to TS sessions across the wireless LAN, which should be reliable enough. TS clients are somewhat network fault-tolerant. Even if the connection is completely lost, the user can log back in to the TS and return to their session, exactly where they left off.
>>
>>3. If you can't set up a Terminal Server, run LAN cabling. Individual runs can be up to 100m long. Running cable may be cheaper than setting up a TS or re-architecting your app.
>
>It looks like he is using SQL Server as the database (good thing!).
>
>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.
>
>There are lots of possibilities here.

Ah, I missed that it's an MS SQL backend. In that case, I agree that connect-on-demand is resource-efficient, and as you point out can be made fault-tolerant by checking for a connection before running a query. But, if the app was designed around the idea of making one persistent connection at app start, and assuming the connection will always be there, that'll require some remediation.