Phil,

> If it were possible, how would I even test for that and how would
> I relocate it elsewhere?

It's extremely unlikely that executable code is damaged (or unreadable), 
and the app still runs without throwing I-O errors. You could run a 
surface scan (CHKDSK, etc), but it might take a long time.

Along the same lines, it's possible that the disk structures are 
damaged, and then the reading of a chunk of the executable/library is 
actually retrieving a chunk of something else, but that should also 
throw major errors! CHKDSK, etc, should flag all structural errors 
(quickly).

If you have a backup of the executable files, just run a file-compare 
(FC, DIFF, etc), between a backup and the current ACTUAL executables. 
That'll also show, or eliminate, possible corruption. If you have no 
backup of the live executables, you could re-build them, but:
   - Sometimes, time stamps, etc, are embedded in executables, so these 
bytes might then show as "differences".
   - You might now be using a new version of a compiler, or some other 
updated libraries, and these would also result in different executables 
- even with no changes to the app.

Separately, could you try a Query (to Insert all the records), instead 
of an ADD? Probably a little slower than ADD, but.....

   - Mike