>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

You have sure gotten closer than I have on this problem. I have seen my error log contain this error in the past year or so and could not find a solution for it. So I would be very interested if someone finds a good answer to this also.