>>>Now you've reminded me... does anyone still have the help file for FP1.0x (or was it in 2.0)? There, in one of the introductory chapters, where the whole discussion of refresh was laid out, the authors explained the shoestring-transaction process. You were supposed to lock whatever tables and/or records you needed before you started a transaction, then do the processing, then flush and unlock. And in the paragraph about the length of transaction, it said "since other users would have to wait for the transaction to end before they can access the records, it's best that the transaction is finished before lunch".
>>>
>>>I wish I had that file somewhere. That'd be help.dbf, with a date between 1990 and 1992.
>>
>>Dragan, look in your e-mail box. :)
>
>Still nothing there... and checked the junk and trash folders as well.

Stupid me. I forgot to press Send/Receive. Ok, it should be there now. :)

>>But... I have the feeling that the real topic of this thread has not yet been discussed. Hope that it will still come.
>
>Well what about this part:
>
>>>My preferred method is to set order to PK descending, then seek(chr(255)) or something like that, then go recno(0). Requires Set Deleted Off, BTW. Of course, restore the order and Set("deleted") on exit.

I've seen similar code that goes like this:

set order to theID descending
locate
lnID = theID + 1

The locate was supposed to be rushmore optimized and also effective if a filter is in effect. Therefore preferable to GO TOP or GO BOTTOM.

But the theme that I really want to discuss here is the use of header locking instead of table locking. I think that this kind of usage is not wellknown.