Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Intermittent error 1705 on CREATE TABLE
Message
De
10/03/2014 08:15:59
 
 
À
07/03/2014 17:18:38
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows 7
Network:
Windows 2008 Server
Database:
Visual FoxPro
Application:
Desktop
Divers
Thread ID:
01595953
Message ID:
01596011
Vues:
61
>>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
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform