While I suggest that you continue to search for the real cause of your problem, you might try having your error handling routine return to from the "ERROR READING FILE" problem to attempt the task again. Your error handling routine might look like:

IF errornumber = 1104
WAIT WINDOW "Error reading file. Press ESC to abort" NOWAIT
nInkey = INKEY(.5)
IF nInkey <> 27
RETURN
ELSE
* crash and burn
ENDIF
ENDIF

I once had a client that was running a VFP5 app on a very unstable network where most of the staff had a connection that passed through 3 routers and used punchdown blocks with CAT 3 wire instead of patch panels with CAT 5 wire. My temporary bandaid error handling routine kept the app going until the client rewired the office so that all the power users had a clean connection to the Novell server. You might also be able to mess with the Client32 timeout parameters to improve the connection.

While I doubt that this is your problem, I'm curious if your app saves any configurations into a FOXUSER.DBF file. If so, you might ZAP it to make sure that some bad environment settings are not being inherited by the users.

As a side note, I generally have my clients point their icons to a batch file on the network that calls the VFP exe file. As I put a new exe into production, I name the exe slightly different from the previous one and the batch file is edited to point to the new exe file. This allows all the users currently in the system to continue working as you install the upgrade. As each user exits and restarts the application, only the new version of the app will be used. This approach keeps the benefits of keeping the exe on the network without the headaches of different versions of the app spread around on local hard drives.

Good luck
David,