>When using ODBC, is there a way to have the backend act as pessimistic when someone pull a record to edit it? I mean, with direct table access, we use RLOCK() in order to lock the record. For example, when we want to increment the next key using the primary keys table, we apply a RLOCK() for a short instance in order to avoid someone else to change that value while we are changing it. This is what I would like to obtain using ODBC. So far, in all the samples, it seems that we pull a set of data or one record to edit. Then, at save time, we will see if our save is successful. The requirement of one client presently is to use ODBC and apply a lock on the backend in order to make sure that a record is not modified by 2 persons.
>
>What would be a bullet proof mecanism for this case?

I only know about one backend -- SQL Server. In that case it is impossible to get a record lock, you can only get page locks. So, you must resort to using a "logical lock". That entails adding a column which holds the "locked" value. When the user gets a record to edit, you check the current value of the locked column -- if it is locked by someone else, deny the edit, if it is not locked, change the value to locked and give the user the opportunity to edit. I have implemented this strategy in one of my client-server apps and it works well. Oh, BTW, I have a stored procedure on the back end that compares the user ID in the Locked column with the ID's of all users logged in. If there is no match, I clear the Locked column. The stored procedure runs every 5 minutes or so (gets rid of those locks still holding on if the user just turns off the computer and goes home). I also make sure to clear all locks in the shut-down procedure.

HTH