Table showing as locked on server

[twestfall]

I have had numerous problems with an application that appears to be locking, and not unlocking a table.

When I run COMPMGMT.MSC on the Windows 2008 R2 Server SP1 running as a virtual machine that is serving up this file. I go to Shared Folders -> Open Files and there is a column there that shows "# Locks". I have no idea what command I can even run in VFP (VFP 9, SP2) that would create a lock that would show up on this screen.

I've tried opening a file exclusive and that didn't work, I've issued FLOCKS and RLOCKS and neither of them created a lock either. However, I have this application that does create a lock that can be viewed on this screen and often they are not being released. This happens from random users, some on virtual machines but most on physical desktops.

Does anyone know where I can start to troubleshoot this?

 

[Olaf Doschke]

The list of open files in the computer management console doesn't auto refresh. Also it only shows locks in file shares, not for any file, and not for local file handles. So you don't see your own opened files. I actually don't know and don't find explained what locks the #locks column counts, but there are many different types of locks. Blocking locks, oplock, range locks. The locks VFP does may not show up here.

So what application locks DBFs, if it's not a VFP application? Have you tried filemon/procmon to see which process as the file open, if it's not a VFP/FP Exe it must be the oledb provider or odbc driver, which has the file handle, not the application exe directly.

http://technet.microsoft.com/de-de/sysinternals/bb896645.aspx

Bye, Olaf.

 

[twestfall]

Hey Olaf,
Thank you for the response. I Realize that the computer management console does not refresh automatically. I will get a call from a user, then refresh the screen, see who the offending user is, have them exit the application and then all is fine. I just can't figure out how and when these locks are getting placed. I was hoping if I could find the offending code in VFP then maybe I could fix it. And it's only this application that accesses these files and causes this problem. I can't help but think it's a flaw in VFP but it's always on the same table. If it's truly a flaw in VFP or the network itself then shouldn't it also create this issue with other tables too?

Tom

 

[Olaf Doschke]

Well, as already said, you have to find out which process, which exe or dll is causing the lock. Computer management only shows the user. It might be anti virus. It might just be the table is your largest file and is scanned longer, or the most often changed file.

Use procmon.

Bye, Olaf.

 

[GriffMG]

I would be thinking along the lines of opportunistic file locking.

It's built in to the SMB2 of server 2008 and you have to remove it if you start getting problems like this.

This link will point you in the right direction:

http://bigmcgeek.blogspot.co.uk/2012/03/opportunistic-locking-smb2.html

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[twestfall]

Thanks Griff will give this a try.

Olaf - I'm not that familiar with Procmon - should we be running that on the server or the workstation? And if it's not VFP causing the locking then wouldn't the locking persist even if the user exited VFP? In our case, as soon as the user exits VFP the lock is removed.

 

[Olaf Doschke]

>And if it's not VFP causing the locking then wouldn't the locking persist even if the user exited VFP?

Well, you said "I have this application that does create a lock that can be viewed on this screen", you didn't sppecify, if that's your own app, VFP or anything else. You were not very specific about that, were you?
Now if you say "if the user exited VFP", do you mean an EXE build in VFP or VFP itself?

Aside all of that, Procmon would be used at the client side, but you can make your development PC A client too. You specify filters of what you want to monitor and get events recorded. Eg monitor the DBF file and Procmon logs all processes of the current PC working on that file, that would include "this application", anti virus software, backup software, anything, so it won't matter what process(es) lock the dbf, you'd find out, that's what monitoring is about.

Bye, Olaf.

 

[twestfall]

Sorry about the confusion. The application I'm referring to is an EXE built in VFP 9 SP2. And I'm convinced it's this application that is locking the file since exiting the application immediately releases the lock. I have been completely unsuccessful at reproducing the behavior on a development machine either by running the EXE or running the application from within VFP. Would PROCMON let me know if it were a problem that GriffMG referred to? I'm asking all these question up front because there's about 12 different users that I would need to monitor and there's no telling if and when the problem will occur again. Today it hasn't happened once yet and we're about 1/2 way through the day. Yesterday it happened 5 different times by 4 different users.

 

[Olaf Doschke]

Procmon can do very much in detail, eg monitor which DLLs are used, which functions within them, etc.

So the situation is, you're quite sure the DBF locked is locked by your app (or the filesystem, windows itself, network, etc). And it has an impact on your app only?
I assumed there were two EXEs working on the same DBF, not two users, two separate applications with each multiple users. Even if there is only your EXE, procmon monmitoring might show you what happened at a certain time the lock appears.

Indeed I found an example of procmon usage where a OPLOCK NOT GRANTED is listed in a procmon log:

http://rickteck.wordpress.com/2011/05/15/troubleshooting-the-system-process-cpu-spikes/

OPLOCK NOT GRANTED would mean there is a lock by userX, not allowing userY to work on the DBF and that could cause that problem permanently until all users or at least the user having the lock exits.

Oplocks are known to be a problem with DBFs and also Access mdb database files, any file based data, but more about slowness and corrupt indexes than about a total lock out of a user.

Anyway, procmon is the appropriate tool to find out very many things about all factors in effect having hands on the DBF file you're seeing locked. You might see other processes listed working on your DBF, eg anti virus, as already mentioned. Alone finding out what components are involved with the locked DBF file will give you more ideas about what else and what in detail to monitor.

Bye, Olaf.

 

[JRB-Bldr]

I have occassionally run into situations where a user had a table tied up when Exclusive work needed to be done on it.

I have used a tool called WhoHasIT (

http://www.gadgetfactory.com/whohasit.shtml

) to identify who that user might be.
And, since sometimes the In Use might be a Network 'hang on' rather than user negligence, if you get the Paid version of the tool, the tool can also Clear the user from the table's access.

Good Luck,
JRB-Bldr