>This question is more of a general standards coding convention question than anything else.
>
>I am working on converting a VFP application written for a network, with a shared VFP database, and tables, into a MySql database for a data source.
>
>After many hours of reading and hopefully grasping the different options avail to do this, I settled on NOT using remote views. and logging into the sql database using a dns-less type connection. nothing is being stored in a dbc. maybe a few dbf- or .mem's for username etc. but I am not getting into the overhead of the DBC and remote views at all.
>
>So my question to your Guru's who know about such things, is specifically about the login - logout process using ODBC in general.
>
>is it proper to login, to the server every time you need to get some data or - insert data into remote tables ?
>
>-
>
>or should I keep the connection handle open and active throughout the life of the users logged in status. ?
>
>the normal user will log in for anywhere from 10 minutes at a time, to 8 hours, but their activity over the 8 hours would be say every 15 minutes. for about a minute or two.
>
>Truly remote (internet users) will most likley log in for up to 1/2 hour and then log out.
>
>Most often, it is for data queries, Most of the users will be doing queries and not too much data insers. The inserted data is coming mostly from merged .txt files, which are processed nightly. the Vfp interface is being done, so the users have a nice desktop application to querry through large amounts of data. and find ususlly one record.
>
>
> My inital thoughts would be it create a connection -sqlconnect() for every sql query, and then as soon as I have the cursor result, issue a sqldisconnect(). but before I start coding with that general rule in stone, I wanted to get a few other opinions to see what hazards I might be getting MySelf into.

It looks like you've got a pretty good handle on the issues already.

If you make a new connection for each back-end operation:

- connection load on the backend is minimized
- performance of your app may suffer, if you have to set up and break down a connection for each DB operation
- it can be a hassle doing this for all data operations, but can probably be minimized by using strategic wrapper functions
- may be slightly more reliable than having a continuous connection; no chance of the connection being down when you expect it to have persisted
- doing things this way is a bit more "stateless", in case you want/need to go to some sort of Web-style front end in the future.