Visual FoxPro - File Access Denied
Our ERP system is a hybrid. The actual data is SQL, but the tables containing user information, profiles, rights, security, and so on are in Visual FoxPro.
I need to get exclusive access to a VFP database. I am deleting everyone from the system using the program itself and that means everyone is logged out. I am getting the following response for the following code:
set excl on
open data l:\M2MDATA\Util\util.dbc excl
The answer I get is: File Access is Denied. I went to Server Manager and nobody was opening files in our VFP directory.
Is there a command in VFP that will allow me to determine who / what is opening the file and / or a way to kill any sessions in FoxPro?
I tried walking, but no luck.
source to share
You might want to check out Process Explorer from Sysinternals (Microsoft).
http://technet.microsoft.com/en-us/sysinternals/default.aspx
You can use Find | File Handle or DLL and enter the name of the DBC file. Process Explorer will tell you the process ID and the process in which the file is open.
If you are sharing a file over a network (file server or peer), go to "server" and start Computer Management. Navigate to Shared Folders> Open Files and you should hopefully see a list of files open on your computer by others on the network.
Rick
source to share
As mentioned by Jeff, one thing can happen when one person's machine crashes and they are disconnected from the network. The server still THINKS that the file is open at some low-level descriptor. Then, when the user reconnects, all the previous settings are automatically activated, returned to the system, then everything looks fine. Also, check the FROM SERVER under computer control, shared drives and who may have files actually open when they might otherwise have an indecent shutdown.
As an alternative to pre-testing this kind of exclusivity on the table, you can try and run the query with .DBC, since that is also nothing more than the table itself ... Something like
nStatus = 0
try
use L:\M2MData\Util\Util.dbc shared
** Ok so far, now try exclusive
nStatus = 1
use L:\M2MData\Util\Util.dbc EXCLUSIVE
nStatus = 2
catch to loTrapMsg
messagebox( "Can't get exclusive use of DBC" )
endtry
if nStatus = 2
** you have exclusive use of it as a simple TABLE
** Now, what do you want to do
use
open database L:\M2MData\Util\Util.dbc EXCLUSIVE
endif
source to share
Perhaps some program crashed when it opened the database (leaving the zombie lock), or the database is connected through a network share that does not release the resource.
In such cases, I usually boil down to rebooting the server where the database is located, or dismantling / reinstalling the disk on which the database is located (if on a SAN or on a network drive).
source to share
Look at the Microsoft support site for Opportunistic Locking and Cached Open settings. You may need to set EnableOpocks to 0 and CachedOpenLimit to 0, as the articles describe. Also, on-access virus checking is notorious for this kind of thing.
In addition to the excellent SysInternals Process Explorer tool mentioned, I use a tool called UnLocker, which allows you to right click on any file on the server and see the locking processes.
There is also another SysInternals tool called a "descriptor" that runs on the command line and gives a lot of information about which processes have descriptors for a given file or files.
source to share
You can try this:
-
Reboot the server (if possible). Now nobody is using it.
-
Get a list of DBC related tables and write a script to open each table separately and exclusively. Do any of the openings open?
-
Perhaps one of the tables is related to a table on another server.
Just some ideas.
source to share
I have this post before and the problem is simple, start Windows Explorer and try to open the folder where the file is located. if you can't access the folder visual foxpro also does. I am assuming you are using a shared folder since you mention that you are using drive L. cmiiw :)
source to share
I had the same problem (no exclusive DBC access) but another reason.
We log access and certain actions in a text file processed using low-level commands (FOPEN, FSEEK, FPUTS, FCLOSE, FCREATE). We have been doing this since April 1st 2000 without any problems.
After a "severe network adverse event" our system is still up and running, but with a hyper snail. Each step done according to the protocol took about 5 minutes. FoxPro apparently repeated the low-level procedures for 5 minutes and finally skipped them (without any notification, by the way).
The text file is in no way part of the database itself. However, DBC was not available with the zombie lock from the machine (off), which also owned the zombie lock in the text file. The DBC lock can only be released after removing the file lock hat.
I don't know how this is connected, but then everything was fine again and remains. A Novell Netware server that I'm not familiar with.
source to share