Re: A row locking problem that baffles all...

>>This is just bad application design and the problem is discussed in most
DB
>>manuals - the record should not be locked until just before the update.
>This is exactly what the client program does. When going to edit the
>record by way of DB aware controls the row lock select is fired to
>lock just before the update.

Then something may be wrong with the way the client is written. The update should occur and then quickly committed to release the lock immediately. It seems the client doesn't commit and holds on to the locks issued.

The client should just do a select.

>>client software can check to see if the row has changed since it fetched
it
>>for viewing (one way to do this is to have a field as an update counter -
>>but I haven't tried this myself).
>You are kidding right? The database in question has thousands of
>tables, and millions of records. How many extra fields is that? How
>much auditing is that?

1. Add in an extra field for sysdate and/or userid that is updated with triggers each time it is updated.

or.

2) Have internal variables holding the original values in your clients to check with the values selected during the lock. In fact Oracle*Forms has a property of the original database value that you pulled in for each item of a block. Received on Fri Jan 15 1999 - 00:27:41 CST