Unfortunately not automatically, as this behaviour depends on your database. Some databases allow row level locking other databases check the state of the original record to see if someone has already changed it. There is no default behaviour. Even the sql might differ as setting up transactions will differ too technically spoken. If you run a desktop application you could try to lock a record ‘for update’ since the lock will be released if you quit the program. But anyone can quit the browser and you are depending on timeouts or won’t be notified at all. That’s why this mechanism is very unreliable if you do that by hand. So in general yes, you cannot. In scriptcase you first select the record and then apply updates. While selecting and you have the intention to update it and your database allows you to lock the record for update you must apply the lock in the onrecord event. But I doubt what will happen if you break the form and start the application again. Is the record released? If your database supports sql syntax for row level locking then you can simply try.
I would not mark every record with fields for ‘inuse’ as they will not be released if the user quits the browser. Also it requires a lot of updates to your tables with live data. Instead I would build a transaction table and put the userid, datetime, tableid, key into that. Then in the onload I would test if the record exists in the table. If it does I would look at the date and decide if the transaction could be valid or not (how much time does a user have to fulfil his transaction). Other option is that in the onload you can delete all transactions older than the allowed time. In the onbeforeupdate or delete I would test in the database if the key is still in the table and if the current user is owner. That way you can test if the user took too long to make his update and reject it with an appropiate message.