Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Help on using VFP as a backend
Message
De
04/09/1999 07:33:37
Guy Pardoe
Pardoe Development Corporation
Peterborough, New Hampshire, États-Unis
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Client/serveur
Divers
Thread ID:
00261177
Message ID:
00261497
Vues:
23
>>The apps local .dbc has a connection that points to the ODBC Datasource. Do the views handle sharing the connection automatically.<<

FoxPro's default does not share connection on remote view automatically. You must make sure of this yourself.


>>When a view is used the connection is opened and when the view is closed the connection is closed. If a connection is open, subsequent views share the connection.<<

Yes. As long as you have set the view to use a shared connection and there is already a shared connection open.


<
If you open a view which uses a shared connection, then you can read it's connection handle and you have a shared connection number which you can use for SPT commands. Be aware that this connection number will only be valid if you have one or more other views open which have used the connection. Once you close the view(s), the handle is no longer available for SPT.


>>Where does the processing take place. In the ODBC driver? On the server (VFP isn't installed there so how could it)? How does that effect things like triggers and field default values? Do they still fire on the remote database or do they have to be handled at the view level?<<

Processing happens on the local PC. Triggers, etc. will still fire. You need to take precautions and make sure you don't put code in your triggers that have any UI. Also, you should experiment carefully with your [trigger] stored procedures because teh ODBC driver does not support the full language set of VFP and the help file (DRVVFP.HLP) is not always clear. Also, default values are not supported through the ODBC driver (if I remember correctly).


Working with the ODBC driver will take more time than traditional VFP programming. Plan for the extra time.

One other point I can make is that if you are careful with table names, field names, datatypes, etc., when you move to SQL Server, most of your code can remain 100% unchanged. It can be a snap if you've planned ahead.

Guy
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform