>>>As part of a complex process, I create a set of DBFs on the fly. (The simple explanation is that they're an intermediate step between an object model and an XML file.) Every now and then, a user gets error 1705: "File access denied" on the CREATE TABLE command for one of these files. Sometimes, it's for the DBF; sometimes, for the FPT.
>>>
>>>The files are being created in the user's data folder, which is in the appropriate location (Users\Public\Public Documents\...). I added code last week to make sure the problem wasn't the file already existing; I closed the table, if it was open and then deleted it.
>>>
>>>

>>>SELECT 0
>>>CREATE TABLE (m.cTableName) FREE &cColumnSpec
>>>

>>>
>>>Any ideas?
>>
>>I designed my basic routines to accept list of names, so I can
>>tbl.tclose (list0_n)
>>tbl.tdelete (list0_n)
>>tbl.tcreate (list0_n, desclist)
>>
>>giving more time for each file handle to be really done by adding minimal overhead to split lists in each method. Sprinkling in doevents if existing code is done otherwise might help, try catch should be able to set up again
>
>Bunching these wouldn't work in the relevant context. They're truly generated on the fly, based on what data is in the object model.

too bad - could not know.

>Again, this is happening only a tiny, tiny percent of the time. I've never seen it myself, but my clients have seen it occasionally over a long period of time.

I ran into a bug in vfp6-8 where the a use did not attach the wanted alias name (in connection with a previous close operation) sometimes in billions of uses - other code ;-) and discussed my "solution" (rigorous encapsulation and looping until wanted alias and actual do match) with Aleksey, who found that having a local with the name of the alias in existance fixed things as well (before fixing in vfp9, my logging of such a mistake has not been triggered in years).

You might try if a local &tcWantedAlias glosses over a bug not fixed and similar in nature...

HTH

thomas