Commit timing issues

Question

Hi,
How do I prevent a procedure committing a row that was committed .10 seconds before the current commit takes place. As this overwrites all the changes made in the earlier commit.
My situation is as follows. I have Form, from which the user can hit the update button which calls a PL/SQL procedure that makes updates to the row. At the same time
there is procedure that runs in a batch job that could make a change to the same row.
I sometimes end up in a situation, in which the form has pulled up data, the user hits the save but in .10 of a second the batch procedure has changed the row below. So when the forms changes gets commited it overwrites the previous changes.
Is there a way to check just before I commit that a change was make to the row.
Or is there someway to minimize the chances of this happening.
Any help will be appreciated
Thanks

Answer 1

I agree with Richard: you need a properly implemented locking strategy.
You shouldn't have a batch process in an OLTP environment that isn't using SELECT...FOR UPDATE or some similar mechanism to gurantee the consistency of the changes it makes.
Likewise this UPDATE procedure ought to lock the row before it does anything else. That's what Forms would do if you were using its native mechanism: if you change a row it issues a lock; if someone's changed the row since you issued a query then Forms tells you to re-query. I don't know why you need a PL/SQL procedure instead but it ought to replicate that functionality.
My tuppence ha'penny's worth.
APC