Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Wireless support for VFP9 app
Message
 
À
15/11/2011 16:36:25
Information générale
Forum:
Visual FoxPro
Catégorie:
Client/serveur
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows Server 2008
Network:
Windows 2008 Server
Database:
MS SQL Server
Application:
Desktop
Divers
Thread ID:
01528963
Message ID:
01528974
Vues:
87
>>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.
____________________________________

Don't Tread on Me

Overthrow the federal government NOW!
____________________________________
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform