>Hey all
>
>Let me start by saying, I've been using this technique in Visual MaxFrame a long time. I would like any extra information that I can get on this approach though.
>
>I just conducted a little experiment. I believe FoxPro obtains a file handle and then fills internal buffers when it first sees a USE command.
>
>If so, then a form with a private data session, which opens tables will take the same amount of time every time and within reason that is true.
>
>However, if I open the tables in the default data session before the private data session form loads, the form itself loads much faster.
>
>I created a simple private datasession form. The load opens the tables. The init returns .f.
>I ran a loop of 50 iterations with DO FORM. It took 120+ seconds.
>
>I then opened the tables first and re-ran the 50 iterations. It took 10 seconds.
>
>In side the form, USED() shows the files are not in use, yet clearly, the file handle and buffers were populated.
>
>So - who can state with authority, what will happen to the data, if in the private data session form, a change is made and tableupdate is run? Will the data make it physically to the file or does it hang around in the buffer?
>
>If power goes off, does the data get wiped out?
>
>Having all the tables opened, does not damage the files during a power failure in my experience. Anyone care to shed some light on this?
>
>Thanks

Hi Mike:

Mi experience is similar of what Walter said.

When you open the tables in normal datasession, the private datasession opens them faster because is reusing the file handle with the AGAIN technique, and reusing a handle is much faster that going and asking Windows that open the file and get the handle.

About this, Rick Schummer have wrote a Blog post on 2007 (http://rickschummer.com/blog/2007/08/i-have-customer-who-is-developer-using.html)

On the integrity side, maintaining tables opened on a network share is not a good option because data buffers keep updating on the workstation, network errors cause data corruption on tables and a power failure can be catastrophic in some circunstances.

SMB worked ok in the past, but starting from Windows XP/2003, SMB2 have replaced it, implementing some optimizations, like OpLock, that are too bad for VFP, as explained here:

http://www.dataaccess.com/whitepapers/opportunlockingreadcaching.html

We are maintaining a 2001 VFP application used by groups up to 70 users concurently, that some years ago had many corruption errors and bad performance. It used most important tables (about 10) opened all the time, and everyday we had corruption on memo files principally on different servers, and network microcuts (is the correct spell?) caused data corruption too.

The first solution approach was to keep tables closed, until a query or update is needed, and in this case we use / update-or-query / close the table, and data integrity enhanced notably, but bad performance keep being a problem.

The solution was to move the application to Citrix servers, so all remote session users are local to the server perspective, and this enhanced the performance about 100% or more.