Houston,

>> Using an SQL UPDATE means that you no longer need to care about such things, it also makes any future upgrade
> to Client / Server much easier.
>
>Gerry and Hilmar, if you have any thoughts on the above I'd appreciate them.

I agree with your general approach to updating and "timestamps"; particularly with an eye to client / server.

I, however, am still doing a lot of "fat client" development, in which case, using RLOCK() is a given (if one wants to maintain any sort of data integrity).

Of course, every app is different and one may be able to get away without using explicit locks .... however, in my case, I have a lot of situations where the "state" of one or more records, in one or more tables, must be maintained while I'm processing a "transaction" (in the general sense). The only way to maintain the "state" of these records is to explicitly lock them for the duration of the transaction. Note that these locked records may never be updated; so a transaction rollback due to "dirty" data never comes into the picture ... the integrity of the transaction is maintained by preventing these records from getting "dirty" in the first place. A way around these locks would be to track the timestamps of these records, but that implies a rollback mechanism if these timestamps change. With locks, however, a transaction will rarely fail, if ever, since one is basically getting all their ducks in a row before even starting the transaction.