Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Intermittent error 1705 on CREATE TABLE
Message
From
10/03/2014 08:15:59
 
 
To
07/03/2014 17:18:38
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Environment versions
Visual FoxPro:
VFP 9 SP2
OS:
Windows 7
Network:
Windows 2008 Server
Database:
Visual FoxPro
Application:
Desktop
Miscellaneous
Thread ID:
01595953
Message ID:
01596011
Views:
60
>>I'm running into something weird and I'm out of ideas. This is one of those things that happens only occasionally.
>>
>>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.
>>
>>Today, the user grabbed a screenshot of the relevant folder after the error occurred and both the DBF and the FPT were there, so it's as if it's creating the table and then having some kind of access problem.
>>
>>There's some code to set this up, but the actual code that's giving the error is pretty simple:
>>
>>
>>SELECT 0
>>CREATE TABLE (m.cTableName) FREE &cColumnSpec
>>
>>
>>And, of course, it's working 99% (actually a lot more) of the time.
>>
>>Any ideas?
>
>- Antivirus
>- Events in Windows System or Application Event Logs
>- Temp file name collision or too many orphaned temp files in folder
>- Network infrastructure issues if folder is not local

Definitely not file name collision because there's a strict naming convention for these files that includes a primary key value as part of the file name. And there's now code that ensures that if a file of the same name exists, we close it and delete it before creating.

The files are being created in the user's data folder, locally, so not that.

I'll check on the other two ideas. The event log may well provide some good clues. Fortunately, my clients are technically savvy. (This application is actually intended for their customers, not themselves.)

Tamar
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform