>>>>>>>>>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)?
>>>>>>>>
>>>>>>>>IME ISO errors have been caused by network or local file system reliability problems - cabling, switchgear, server, power failures, computer crashes etc. Short-term solution for me has been to reindex, preferably after replacing suspect CDX files with known good ones (so that tag information is known to be correct). In the longer term, address the reliability issues - look at Windows event logs etc.
>>>>>>>>
>>>>>>>>The Wiki article at http://fox.wikis.com/wc.dll?Wiki~InvalidSeekOffsetError1103~Wiki seems to think this error is caused by file system reliability or buggy printer drivers. If your case is the latter moving to XML may not help at all.
>>>>>>>>
>>>>>>>>Amusingly VFP9 SP2 help says "Record your recent actions while using Visual FoxPro and then call Microsoft Support".
>>>>>>>
>>>>>>>I wish there were a way to cause the ISO error on-demand; to test it with XML files. I read much on what is causing the ISO but it does not help since I cannot "catch" it within the application (unless I put every line of code in TRY/CATCH).
>>>>>>>I saw the help of that error in VFP help; pathetic.
>>>>>>>Thank you.
>>>>>>
>>>>>>To create the error just issue ERROR 1103.
>>>>>
>>>>>This is not what I meant. I want to "corrupt" memory such that it would cause 1103 when opening DBF and then try to open XML.
>>>>
>>>>AFAIK memory is not "corrupted" before or as a result of an ISO error. I think what happens is a bad entry in a CDX file causes a SEEK to try to access part of an associated DBF or FPT file that is before the beginning or past the end of the file. Similar to programs in Windows trying to access memory addresses that don't belong to them, which cause C5 errors.
>>>>
>>>>For performance reasons some or all of the CDX or data file(s) may be in VFP memory, but even in the event of ISO errors occurring that memory would not be structurally corrupt, it would just contain one or more bad pointer entries/values in the CDX section.
>>>>
>>>>So, if you can handle an 1103 error (via TRY...CATCH or whatever) you should be able to proceed with subsequent XML operations.
>>>
>>>If your theory of ISO having to do with CDX or DBF or FPT is true, doing away with them (CDX/DBF/FTP) and replacing them with XML should minimize the problem. I will have to see how much work it will be on my part to convert all meta to XML.
>>>Thank you.
>>
>>ISOs are symptoms of something else being wrong. If it's just one site/client with ISOs it might be better trying to find the root cause(s) than to develop workarounds.
>
>The error can happen to any number of customers and each customer runs my app on many PCs. It is very time-consuming for me to "deal" with each case. The customers IT are no help at all. So I need to find the way to minimize the problem no matter what other causes.

In another message you said "My app is also using SQL Server and the meta data are in the executable." Do you mean you've included DBF/FPT/CDX files in your executable? If so are you sure the CDXs you're including are known good?