Who locks the record?

[MontyItaly]

Maybe I ask too much.
In an environment of Win XP client and a server WIN server 2003
using simple DBF tables CDX-where the blocks are managed by hand with
RLOCK () it would be possible to determine which user (PC) locks a
record?

Thank
Monty

 

[Olaf Doschke]

Yes and no. Your users would need administrative rights on he server with the DBF having locks. And that's not really practical to give such privileges to every user.
The solution with adminstrative rights is shown here:

http://www.berezniker.com/content/pages/visual-foxpro/who-has-files-open-network

This works at least on the file level. You might also find out, where and how the OS maintins which client and therefore which user locks single rows.

A simple solution would be to write on your won, who locks what record, by writing that to a log table or text file right before or after you RLOCK records or UNLOCK them. You also might fill a field with ID() after you locked a record, which also is a sure sign you locked it, as you can write to it.

The problem with that is, that there are not only manual locks but also automatic locks, anytime you write to any file, not only in foxpro, this is very core definition of the OS to maintain file health and that is prioritised to availability of the files to all users.

What makes this more complicated is Raid and SAN and errors of the OS or network. I can tell you stories from over 10 years experience in small and large networks with switches playing a role, etc.

So, if you have problems with locks, from my perspective the easy way out is to not try to stabilize VFP, he OS, the LAN, switches, drivers, memory caches, etc., but to switch to a server database. A real server database decouples the data from the clients and thus may only have local problems with this, you can easier address.

Unless you only have a few clients in a small otherwise well working network, which should work, and unless you not find a logical error in your locking/unlocking design, then it's a sign you reached a limitation, no matter if data volume and number of users is low, the problems arise with a large enough number of concurrent access, and that also can occur with otherwise unproblematic seeming conditions. In the end as I was in such situations we only partly resolved instabilities, with the help of on site network administrators and experts on the field of network protocols and then as the final step moved to a real client/server database decoupling the clients from the data storage via the server side process queuing and prioritizing the requests and maintaining the resources like the file or files making up the data.

So, what's your overall situation?

Bye, Olaf.

 

[Mike Lewis]

Hi Monty,

Short answer is no. As far as I know, the only way to do this would be to create your own table for keeping track of the locks. Every time a user successfully obbtains a lock, he writes a record to the tracking table; the record would contain the user ID, table name and record number. When he releases the lock, he deletes the record. If you fail to get a lock, you can search the table to find out the ID of the user in question.

There are several difficulties with this approach. Not least of these is that the system will fail if the user crashes out while the lock is in force.

Maybe someone else can suggest something better.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[MontyItaly]

Thanks for the advice.
Olaf, there is no problems in the network. I just wanted to give the message 'record locked by Johnny'.
Too complex to manage the table with the record locked.
All that remains!

Monty

 

[Mike Lewis]

Monty,

I can only add that, in my experience, most VFP programmers don't do this. We simply tell the user that the record is locked. The important thing is to design the application in such as way that no record ever remains locked longer than necessary.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[DSummZZZ]

You can show who has tables open and if they have record locks using API calls (which is what my 'Open File Lister' app uses), but like Olaf said. The user must have sufficient rights on the server. Not necessarily "Administrator" tights, but they at least must have "Server Operator" rights.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Olaf Doschke]

>Too complex to manage the table with the record locked.
If that's your only problem,
add a field user C(50) and after each successful RLOCK() write ID() to it. After each unsuccessful RLOCK you can still read that field and display it. It will have the computer and windows account name. You can of course also store just the name or user nickname or whatever you want. It's not much code needed, indeed much less than determining who has locked files.

There is nothing inbuilt into VFP you oversee, VFP does not know who has locks, it merely is requesting locks from filesystem and in case of fails forwards them, but the OS doesn't tell the user, unless you have more privileged. It's good to know you just need "Server Operator" rights, but it's not worth the hassle, merely write the user having made the lock right after the RLOCK and you're done with that feature. Hopefully you have a central class for database/table access, to which you can apply that change, the only hard thing then is the database update to have a field in any relevant table for the locking user.

Bye, Olaf.

 

[MontyItaly]

Considering my situation the best solution is: update database to have a field in any relevant table for the locking user (relevant table are 7-8 not more).
Good idea, thank Olaf.

 

[Mike Lewis]

update database to have a field in any relevant table for the locking user (relevant table are 7-8 not more)

Why not have a single table, to hold the locks for all the other tables? That way, you wouldn't have to modify the existing table structures, and you could use the same code in all cases.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

That's another idea, Mike. But having the same fieldname in all tables you can also handle this with a single method working on an alias parameter or the current workarea. And what's elegant about the field in the same table is, it veryfies you have the write lock and no other can overwrite it, unless it's unlocked. A seperate table would also be shared and could therefore be tempered with, intentional or not. So the main advantage of a seperate table is the lower impact on the database. You can add a table even at daily use, while ALTER TABLE needs exclusive access.

Bye, Olaf.

 

[Olaf Doschke]

...that was only half a thought: So the main advantage of a separate table is the lower impact on the database. You can add a table even at daily use, while ALTER TABLE needs exclusive access. But the advantage of a field per table outweigh that in my opinion. In the end it's a matter of taste, what ads to the change of each of the about 8 tables is code working on them now, not knowing that field, eg it might show up in a grid, where it shouldn't show up, etc.

Bye, Olaf.

 

[MontyItaly]

I think my situation is conducive to a field per table.
I have a function myrlock() and there I can put a unique code.
All grids display only selected fields.
Then every weekend shut down the server and saturday morning I can make the changes exclusive (reindex, pack, modify structure ecc...)

Monty