>In the beginning of the year I spent much time trying to resolve errors of "Invalid Seek Offset" and "Error Reading File" that occured at only one client location. I never did find the problem then... but just yesterday I found this out...
>
>I opened one copy of VFP to access data across our Novell 5 network to do some testing on a login exe that updates local workstation driver tables with their network parent. I opened a table contained in the database from the command propmpt and thus opened the database also. I then logged in again to cause my script to call my VFP exe. When the login was complete and I returned to vfp and tried to use the same table (which I had closed, but the database was still open) I received and "Invalid Seek Offset". Now I had another VFP window open that I was using but I had closed the database there and all seemed fine. So I theorized that when I logged in again, Novell logged me out first and then back in thus changing some sort of datasession ID or something... So all of a sudden it occured to me that if a user temporarily got disconected, but was reconnected without their knowledge via Novell's autoreconnect that subsequent program calls to tables in the already open database would
>cause an ISO.
>
>So the question... Is there a way to monitor the for loss of connection and thus compensate for it when novell automatically reconnects? Or is there some sort of datasession ID that needs to be fixed in the datasession object?
>
>All thoughts, theories and guesses are welcomed.
>
>Shawn Burke

I had similar problems on a TCP/IP network running Win NT but could never get VFP to re-connect to the open tables. Windows Explorer could recover but VFP could not. My solution was to close all open tables and shutdown the app when 'Error Reading File' occurred. To attempt to catch the error before it gets to such a critical state, we 'Ping' the local connection, the default gateway and the network server. If the error is caught by 'Ping', then a Retry can usually recover and the app continues.

I believe you're on target with the question "Or is there some sort of datasession ID that needs to be fixed in the datasession object?" but I don't know what that would be.

Here's a quick test: Start VFP and open a table on a network connection, unplug your network cable, 'browse' the open table and an error will occur. Now, plug the cable back in, access the connection using Explorer and all's ok, except for FoxPro which can only access the table if it's closed and re-opened.