Doug,

Great Idea - funny how once you have had one idea it is sometime difficult to re-visit the fundamentals - I was stuck with the idea of modifying the structure of each table... silly me. Adding a separate 'locking' table is a much more palatable, if clunky, prospect....

I'll keep looking for a information/tool that will work with the lock at file/OS level.....

Thanks for your help

Jon Nelson

>Jon,
>
>No, I don't know of any docs other than that which is in the help file..
>
>The 'trick' is finding a product that absolutely respects VFP's locking scheme, absolutely stays out of the way and yet is absolutely "on top" of each and every change. The only product I know that does this is VFP. <g>
>
>As far as altering any table structure I need to perhaps be a little more clear here. I would add a new table, not alter the structure of any existing table. In this new table you could track what was goiung on.
>
>I know it's a clunky solution. But, it works....
>
>If everything's in a DBC I suppose you could use some RI rules as well...
>
>Best,
>
>DD
>
>>Doug,
>>
>>Altering the table structure and wrapping the RLOCK/UNLOCK functions is an option but I would prefere not to alter the prodction table structure....
>>
>>If VFP is taking care of the locking it must be done at the file level... therefore it must be writing locking information to the database header or flagging each record??? I've been digging around for some info on the DBF file structure (e.g. http://www.e-bachmann.dk/docs/xbase.htm) and there are several areas marked as 'reserved' - do you know of a comprehensive document on VFP file structure with regard to record locking?
>>
>>Many thanks
>>
>>
>>Jon Nelson
>>
>>>Jon,
>>>
>>>I doubt that you'll find that information inside of the O/S as it is managed by VFP itself. You might go over to www.hallogram.com and see if they have any API libraries that could help.
>>>
>>>Other than that you'll need to roll your own. It's not too difficult - all you need is a table that contains some basic information like:
>>>
>>>User's Name
>>>Table Name
>>>Record Number
>>>Date & Time of lock
>>>
>>>etc... With this you can build your own locking semaphore table and then 'wrap' your RLOCKS with it.
>>>
>>>Best,
>>>
>>>DD
>>>
>>>>Doug,
>>>>
>>>>I've tried the usual Server manager - this shows open files but not FLOCK and RLOCKS.... Are you aware of any other tools (Perfomance Monitor/Resource Kit..)?
>>>>
>>>>Cheers
>>>>
>>>>Jon Nelson
>>>>
>>>>>>I'm trying to resolve a deadlock situation on a multi-user VFP database using free tables.
>>>>>>
>>>>>>Is anyone aware of any tools (running on an NT Server) that show which user (at a connected workstation) has a record/file lock on a table? Ideally I would like to be able to see that user X has table name YYY open at workstation ZZZ with a record number NNNN locked...
>>>>>>
>>>>>>
>>>>>>I've spent some time digging around trying to find info on this and have looked at Win API NetFileEnum - but this seems to be a dead end...
>>>>>>
>>>>>>Any information on exactly how record locks are applied at a low level would be appreciated (is this to the actual DBF file or is this done using some other operating system mechanism)???
>>>>>>
>>>>>>TIA
>>>>>>
>>>>>>Jon Nelson
>>>>>
>>>>>
>>>>>Jim,
>>>>>
>>>>>Well, you can look at the System Tools stuff built in and find out who has what resources open but programatically I don't really know off hand.
>>>>>
>>>>>Check out Communications Horizons. Neil Weicher usually has something that works. Bright guy.
>>>>>
>>>>>Best,
>>>>>
>>>>>DD