Larry,

Hmmm... I thought that VFP did some of the managing of this stuff. Doesn't VFP help manage all that in memory and as a result it gets a speed boost? I guess I need to revisit all this to get myself back up to speed. <g>

Best,

DD



>Jon,
>PMFJI, but locking is done at the OS level. Different netwrok OS handle it differently but the best approach (IMO) is done by NT and Novell. Other OSes may use the same approach but since I am not familiar with them, I won't state it here.
>
>When VFP issues a locking command (rlock/flock), the OS modifies a flag associated with the file/record address on disk that determines if something is locked. This is not the physical disk, it is an index (for lack of a better word) stored in memory. Because is is just an index, it doesn't affect other files trying to access the file. They can read it. However, when VFP or another application attempts to lock that file or record, the OS checks the index and returns a positive or negative response if the index is available. Exclusive use is a different story. The actual physical location on the disk is locked.
>
>HTH.
>
>>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
>>
>, snipped >