tags:

views:

867

answers:

7

Our ERP system is a hybrid. The actual data is SQL, but the tables which contain user information, profiles, rights, security, etc is in Visual FoxPro.

I need to get exclusive access to the VFP database. I remove everyone from the system using the program itself, and it indicates everyone is out of the system. I get the following response to the following code:

set excl on
open data l:\M2MDATA\Util\util.dbc excl

The response I get is : File Access is Denied. I went into server manager and nobody has any files open in our VFP directory.

Is there a command in VFP that will allow me to determine who/what has the file open and/or a way to kill any sessions within FoxPro that do?

I tried googling it but had no luck.

+1  A: 

It is possible the some program crashed while it had the database open (leaving a zombie lock) or the database is connected via a network share that isn't releasing the resource.

In such cases, I'm usually reduced to either rebooting the server where the database is located or dismounting/remounting the disk where the database resides (if on a SAN or network disk).

Jeff Leonard
+1  A: 

As mentioned by Jeff, one thing could be when a crash on one person's machine, and they get disconnected from the network. The server still THINKs the file is open at some low-level handle. Then, when the user re-connects, all prior settings appear to auto-magically get released, get back into the system, then all appears to be fine. Additionally, check FROM THE SERVER under computer management, shared drives, and who may have the files actually open even though they may have had an ungraceful disconnect otherwise.

As an alternate to pre-test such exclusiveness on the table, you may want to try and run a query against the .DBC since it too is nothing more than a 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
DRapp
+3  A: 

You might want to check out the Process Explorer from Sysinternals (Microsoft).

http://technet.microsoft.com/en-us/sysinternals/default.aspx

You can use the Find | File Handle or DLL menu option and put in the name of the DBC file. Process Explorer will tell you the process ID and the process that has the file open.

If you are sharing the file on the network (file server or peer-to-peer), head over to the "server" and run Computer Management. Drill down into the Shared Folders > Open Files and you should hopefully see the list of files opened on the computer by other users on the network.

Rick

Rick Schummer
A: 

Look on Microsoft's support site for server Opportunistic Locking and Cached Open settings. You may need to set EnableOplocks to 0 and CachedOpenLimit to 0 as the articles describe. Also on-access virus scanning is notorious for this sort of thing.

In addition to the excellent SysInternals Process Explorer tool mentioned, I use a tool called UnLocker which lets you right-click on any file on the server and see the locking processes.

There is also another SysInternals tool called 'handle' which runs at the prompt and gives lots of information on what processes have handles on a given file or files.

Alan B
A: 

You could try this..

  1. Reboot the server (if possible). Now noone is using it..

  2. Get a list of tables linked to the DBC and write a script to open each table individually and execlusively. Do any of the opens fail?

  3. Possibly, one of the tables is back linked to a table on another server..

Just some ideas..

+1  A: 

i have got that message before and the problem is simple , run windows explorer and try to open the folder where the file located. if you can not access the folder , so does visual foxpro. i assume you are using sharing folder since you mention that you are using drive L. cmiiw :)

cakyus
A: 

I had the same problem (no exclusive accesses to DBC), but another reason.

We are protocolling access and certain activities in a text file handled via low-level commands (FOPEN, FSEEK, FPUTS, FCLOSE, FCREATE). We are doing so since april 1st, 2000, without any problems.

After a "severe adverse network event" our system still ran, but at hyper-snail speed. Every action protocolled took about 5 minutes. FoxPro obviously retried the low-level procedures during the 5 minutes and finally skipped them (without any notice, btw).

The text file is by no means part of the database itself. Nontheless, DBC was not accessible with a zombie lock from the machine (powered off) which also was the owner of a zombie lock to the text file. DBC lock could only be released after the thext file's lock hat been removed.

No idea, how this is connected, but afterwards, everything was fine again and still is. Server is Novell Netware, which I am not faniliar with.

Regards, Klaus-Peter

Klaus-Peter Thiele