>>Hi,
>>Of course, many messages have touched on the subject of how to get around the dreaded "Invalid Seek Offset." So here is another one.
>>
>>Sometimes customers send me an error of Invalid Seek Offset that happens when the application is reading from some meta .DBF file included in the application .exe file. My question is, do you think the chance of Invalid Seek Offset would be less if I change the meta data from .DBF to .XML?
>
>If you're INCLUDEing the DBF/FPT/CDX in the EXE there should be no way they can get corrupted (especially the CDX, corrupted or out-of-date CDXs being the most common cause of ISOs). I assume of course that you're 100% sure those files are not out-of-date or corrupt before you build them into the EXE.
>
>To use built-in files VFP has to at least load them into memory and they may or may not have a temporary disk presence (as temp files). These actions may be subject to interference from antivirus programs. You might want to make sure your client excludes your EXE and the temp files folder(s) from real-time AV scanning.

Well, nobody is 100% sure of nothing :). But I think if the files were corrupted, the error would pop up more often. In my own experience I concluded that Invalid Seek Offset is caused not by a DBF/CDX being corrupted but rather when the computer memory is "corrupted" and the application does something with a DBF table. This is why I thought that if I replace the DBFs with XML (for my meta tables) I could reduce the cases of IOS. The problem with IOS is that I cannot catch it with TRY/CATCH and therefor it causes a run-time error when it happens.
And I do tell the customers to exclude the app from AV but some do it and others don't. I can only ask.
Thank you.