We’re trying to suggest that you should NOT use row locking.
I’ve been there see it done that and watched an “enterprise” application lock itself up because developers used row locks.
It’s not great when the ONLY way to recover is to thane the DBA kill sessions that are deadlocking others.
But feel free to learn this lesson for yourself 
Some people have to learn by doing, I guess.
The first time someone opens record & it’s selected for update and they go for coffee, to the washroom, lunch etc
Let the fun ensue
i think that i will choose to create a table “lock” with primary key “tableName”+“idRecord” and with fileds UserLock, TimeStartLock
then when i try to lock a record i try to write in this table tablename,idrecord,userlock, timeStartlock
if there are no error the record is locked by me …
then i update real record/records, then i delete all records in table “lock” with userlock=me
then i run every 20 minutes a procedures that clean table lock from records where timeStartLock is >20 minutes (or less)
Put a timestamp column on every table - this is the LAST time the row was updated
Then your queries to get the data for someone to work on also get that timestamp
And when you go to save you see if the timestamp you got still matches & if not then you can do whatever is appropriate (ask the user what to do, abandon their changes & grab the new data, etc)
Really simple & VERY effective
No extra lock tables required
[quote=62085:@Jury Buono]i think that i will choose to create a table “lock” with primary key “tableName”+“idRecord” and with fileds UserLock, TimeStartLock
then when i try to lock a record i try to write in this table tablename,idrecord,userlock, timeStartlock
if there are no error the record is locked by me …
then i update real record/records, then i delete all records in table “lock” with userlock=me
then i run every 20 minutes a procedures that clean table lock from records where timeStartLock is >20 minutes (or less)[/quote]
Out of interest what is the scope of your project?
A part from being overly complex, your proposal has one other issue - if you store all the locking information in one table, you’ll force every user to go over that table, which can result in poor performance as each user queues up to get their go at the table.
number of users : from 70 to i don’t know
number of concurrent users : from 10 to i don’t know
database… : n.40 tables , 15 views, 10 procedures, size >3Gb
users has maximum competition on 1 table that contains dates and places available but
each record has these fileds
date, HourStart, HourEnd, TotalePlaces, PlacesOccupied,placesId
for each day/placesid can may exists much records …
example if places is a places where peolpe stay for 15 minutes the total records for this place for specific day wiill ares
(24h60min)/15min=96
if minutes are 10
(24h60min)/10min=144
i have from 100 to 200 places the total records for each day will be min 9600 records
total record per year in this table will be 3.504.000 records
users must can change the value of placesOccupied of each record… but i must manage the concurrency
and users no change 1 record for time, but 200,300 records 2,3 days …