There are two issues, one is a DB error that Ann has addressed, and
the other issue is simply that two transactions tried to change the
same record.

This is not something to be feared, but rather use it as a mechanism
to prevent dirty update problems etc.

My simple method, using an employee edit screen example:

1. Use no-wait transaction.
2. update employee set id=id where id = :EmployeeOfInterest;

At this point one of two things will happen.

a) I will receive an exception because another transaction has this
record locked. I then display a sensible you cant change this because
someone else is changing it type message.

OR

b) The query runs successfully. This will create a record lock on the
EmployeeOfInterest record in the employee table.

3. The user then makes their changes and hits save.
4. The queries are run within this transaction to update the database
with the new details for this employee.
5. The transaction is committed.

Notes:

I assume the following:

1. The update triggers on the employee table should not take any
action that would result in locking other records unneccessarily.
2. That it is preferable for the user to be denied access to edit the
record in the first place than for them to make the changes and the
save be denied, or having to deal with synchronising changes.
3. In my design, the employee record is pretty normalised, so even
though the record lock exists on this record, it is unlikely to cause
problems elsewhere in the system.
4. Always use try / except / end blocks in this case to ensure that
if there is some problem, the record lock is released because the
transaction is rolled back.

Note also that it doesn't take much work (another transaction and
another table) to log which user is currently using the edit so you
can display a more informative error message.

Adam