>>>>>I have converted my app to SQL Server database. So this has eliminated the corruption of the application DATA. But my app still, on occasion gets the "Invalid seek offset" error. The error happens when the application tries to access/open/load meta data which is still in the DBF format. I believe that "Invalid seek offset" is caused by some kind of PC memory corruption (be it from a buggy printer driver or some other).
>>>>>
>>>>>But I am thinking; what if I replace all my meta data tables from DBF to XML format. Will it eliminate this "Invalid seek offset" problem? That is, do you know if the corrupted memory is only causing the problem when opening DBF files? Or any file(s)?
>>>>
>>>>It has been a long time since I resolved that. The illigal offset in my cases Always had to do with Network connections that were dropped (even briefly). Since we've upgraded to SQL server and hold all the meta data locally or embedded in the executable, I have not seen it since.
>>>>
>>>>Walter,
>>>
>>>My app is also using SQL Server and the meta data are in the executable. But still, once in a while, I get messages (from customers) of that dreaded ISO error. This is why I am thinking of changing meta to XML. I presume that your meta data is DBF, right?
>>
>>Yes. DBF. I've never encountered problems with that. Where is your executable run from? From the network or from the workstation? If from the network the problem could just be that the network connection is lost. VFP reads the executable when running code. If the networkconnection drops, the executable cannot be read anymore and an Illegal Seek offset will be thrown.
>>
>>Best is making sure using a launcher and make sure it is run locally from the workstation.
>>
>>I do not think that a change to XML would change anything. The cause is unrelated to the DBFs if they are embedded in the executable.
>>
>>Walter,
>
>My application EXE is always run from the network drive (shared folder). So it does make sense; now that I think about it, that networking issue could cause this problem. I don't want to change to a launcher and local drive. It may resolve some issues and introduce new ones.
>And I will not convert to XML. But I will add some TRY/CATCH code to the places where application loads meta tables. This way, if ISO happens, the user will have a choice to try it again. Just in case the networking issue was a glitch.
>Thank you.

It is IMO bad practise to run from the network. If the workstation goes to sleep/hibernate, wake up, it will have lost the networkconnection and you'll have exactly this problem. It might not have to do with any DBF, but running a function or form or even displaying an image could cause this.

VFP exes are not 'real' executables. When the exe runs, it will read data from the exe file during execution. Normal PE executables will first load entirely in memory before they are executed.

using TRY catch would not resolve your problem either because the if the connection is lost, it will stay lost even if the network comes live again. It might not even be able to load the code to be exectuted in the catch, because it has to be read from the executable.... which it cannot.

Really the best solution is to use a launcher... it will make your program faster as well.

Walter,