>>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...
>
>The ISO ussually comes up when VFP is unable to load a resource (from e.g. a network). It might throw the same error when an index is corrupted, but I think those cases were rare.

Are rare now. In the past... mileage varied. Used to happen more in industrial settings, where the coaxial network cable were physically near high power cables, Röntgen machines, welders, big electromotors and pretty much any electric contraption which wasn't properly shielded or its power consumption wasn't smoothed out by electronics. Any spike may cause an EM pulse in the vicinity, which your network card may interpret this way or other... ending up in a corrupted index sometimes, which you discover a week later when you hit that node again. Near impossible to catch when it happens. You only get a hint when you move the cables to go some other way and the troubles suddenly stop.