>>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.

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.

Tamar