If TABLEUPDATE() fails, an error handler won't catch the error. You have to test it with AERROR() on the next line of code immediately following the call to TABLEUPDATE(). Then either commit or rollback the transaction.

Also, Pessimistic locking does not scale well and is not considered good practice. Since a record is locked when an edit begins, a person can begin an edit then walk away from their machine and lock out the whole network. Use Optimistic locking instead. With it, the record is only locked for the amount of time it takes to commit a changes. You can also write custom conflict resolution code to flag whether someone made changes while you were editing. There are some good examples of this in the Developers Guide.

Charlie