>I used CALCULATE here only to make clear that the programmer has 'all the time of the world', so to speak, to retrieve the ID. It could've been a quick method using an index combined with SEEK or GO BOTTOM.

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.

Still much faster than calculate... but I actually do select max(key) - only the first time a particular key has come up since the app was launched. The list of visited keys is kept as a comma delimited list in a property of _screen. This works for all those situations where the keys table and the actual data may get out of sync.

>During the time that the header is locked and the unlock is done, nobody else can do this same thing! This is the big advantage ofcourse, but it also implies that the timespan shouldn't be too long and should also not contain user input, because a user might decide to have lunch in the mean time.

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.