First of all, I hope you try Alex's excellent suggestion of putting in a TRY-CATCH structure and outputting exact details of the error, rather than trying to "think it through." That is sound advice.

That said, I ran into something similar when porting a VFP 6 to VFP 9. The code had not changed at all but it stopped working (on a sporadic basis). I never did nail it down -- due to time constraints I just recoded it slightly and moved on -- but my theory was VFP 9 was getting confused between temp files with names that were identical through X number of characters. It seemed to be using only part of filenames which were not fully unique, then lost track of which file was which.

Can you post the relevant piece(s) of code without revealing anything proprietary?


>This is happening on my local machine and I have admin rights, so I don't think it's that. The file is definitely not open somewhere else. The file name is completely legal (it contains only letters and underscores - no spaces - and uses the extension .txt - it's "longish", but no more than 50 characters). The file name is stored in a property and used each time via the property, so it does not change. Me thinks it's a bug. I am just doing what I've had to do before . . . delete the file before creating it again. Thanks for the reply.
>
>>Right, it shouldn't be happening.
>>Look at it logically. Start excluding all the possible causes as you already did with some.
>>
>>Filename and path do not change yet it doesn;t work after a while. It is either permissions, file in use somewhere or Windows does not like the file name (illegal name).
>>
>>Enclose the file write in a TRY..CATCH and when it fails show a messagebox or something with the actual path and file being written including all characters and spacing. See what is it *really* trying to write.
>>
>>HTH