Having the time to track it down is the problem. Deleting the file before creating it solves the problem, so I can move on to other things. I don't think there's going to be much bug fixing going on in Sedna (and I suspect this is a bug). The guys still on the team are not guys that enjoy that type of work (or at least that's my impression). They want to do the bleeding edge stuff and now they've got a new playground with their .NET work. Can't blame them too much, but I wish the team would do more bug fixing. I think they fall short in that area.

Anyway, the code that is executing is:

copy fields partnum, page_num, dlr_code, list_price;
to (thisform.OutfilePriceSheet) delimited with "" with character tab

where the property OutfilePriceSheet is

Catalog_Price_Sheet.txt

Thanks for your reply.


>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