>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.

Changing to XML would make it local... either the whole XML string, with all its redundancy, would sit in the memory and be interpreted sequentially or with whatever internal indexing the XML DOM object uses - we know its speed drops squarely with the size - or would be turned into a cursor, which is then again local, sitting in memory or physically somewhere in the %temp% folder. Both ways, it introduces an overkill, the information is packed into a loooong string which then has to be parsed to become a table with random access for retrieving the data.

IIRC, the ISO was due to screwed up indexes, where the offset (calculated as header + recno()*recsize()) would return a value not between bof-eof. These would happen for any hiccup when writing to disk - be it network card, faulty memory, network cable or other hw fault, power brownout... anything. With dbfs being inside the executable, the write errors are near impossible (unless it happened while building the exe and went unnoticed for a long time), so I'd say that in his case it's a network glitch when reading the exe. Launcher...