Larry, John, thanks for caring.

>
>How's tricks?
That is trucks I suppose. Your typing is improving ... :) Anyway, I left the Brinks group. Time to change my UT profile I guess. Pity, kind of liked this one.

But then ... and I quote "-- on to the problem --"

>
>You could do this if you like.

True. It's much easier than I thought. All you need is a meta table really. And since I open my table with a wrapper tableBase object that gave me conscience problems because all I used it for was to open the table and pigguy backing on the out of scoping to automatically close it. People who have never worked in 2.6 cannot understand why this is so cool :).

So I added the lLock() method to this tableBase class. This method generates the key, using the key() function and & you can obtain the value of the key, and concatenate that to the name of the table. Then it proceeds by rlock()ing. Depending on the result of this, the locking information is then conveyed to the meta table. If the key exists it the record is simply overwritten, otherwise a new record is added. If the rlock() returns false, then the record in the metafile is simply read and a warning/error message is generated containing the user name, the station and the timestamp.

The metafile is managed by a global oLock object that opens the metafile, save()s the locking information or read()s it back. These methods (save(cKey) and read(cKey)) are called by the tablebase objects.

The only limitation is that you need a key, you cannot use random access. But who does these days right? And you may encounter some performance problem if you lock multiple records (got that one from July's Foxpro advisor:)).

Come to think to it, it is almost easier to code than to describe :).

Thanks again and regards.

Marc






and actually rlock()s if possible and calls the lock() method of a global oLock object if it succeeds or its (oLock's) cInfo() method that returns the locking information.

oLock opens the metafile, locks(

SBT (accounting software) did something like this (and may still do AFAIK). If you need that kinda tracking, maybe you are better off moving the base tables to SQL Server and letting the SQL Server native transaction log do it for you.