>Occasionally while running a VFP app across a tenuous network connection, we get a 1104 or 1105 error with DBF i/o. Once that happens, it seems there is no way to recover other than closing and re-opening the table. In other words, once the network connection is temporarily disrupted, VFP considers that open-file connection to be lost even if the network disruption is only for a moment. Furthermore, any grids on any forms that map to the table also lose their connection and essentially go blank.
>
>What is the best way to recover from a 1104/1105 error? It really, really pisses off my users to have a form completely filled out, click the "OK" button, and then get hit with a (currently) unrecoverable DBF i/o error.
>
>In particular, how to recover without creating a cascade of additional errors. For example, if you issue a "USE IN XXX" command to close the table in workarea XXX, will that fire another error because VFP has lost the file connection? And etc every time you try something with those disconnected tables?

It will inevitably error out; you can only exit gracefully. One thing I've learned over time was to open the same table again under a different alias, and do some benign change there (add a period to a string then remove it, or something like that) then close it. That seems to flush the buffers properly (even under 2.6) and while it doesn't fix the situation, it prevents table/index corruption.

Also,

use in select("myalias")

will not error out if the alias is not in use.

One way out of this, if it happens often, is to detach. Don't use direct table aliases in your forms; use cursors you created. At save time, check whether the table is open, and if it's not, well, open it, then have some code which will update it from your cursor. That's practically views done manually, and I've used a framework which did the updates automagically. The nice thing about it was that it took very little time to switch to updatable SPT cursors if a move to SQL was in order.