Thanks Fabian,
I mean something similar to this excerpt I found about Oracle Forms :
BEGIN OF QUOTE
"Oracle forms for example will issue a SELECT for UPDATE on any row you attempt
to update or delete from the GUI. It does this since you read the row out at
time T1 and you delete it at time T2. It wants to make sure that in the time
between T1 and T2 -- no one UPDATED that row. It wants to make sure you do not
delete the row without having at least looked at the modified information (that
would what is commonly known as a "lost update"). It also does this to ensure
that when the time comes, the delete will proceed in a non-blocking fashion.
The select for update forms puts on the row ensures
o the row was not changed
o the row will NOT be changed
o the row is locked by you and you will be able to delete it.
So, in forms the logic is something akin to :
1) read the data out with select t.*, rowid from T
2) let the user look at the data
3) when the user decides to delete the "5'th" row in the result set, forms will
issue:
select t.*, rowid from T
where t.c1 = :block.c1
and t.c2 = :block.c2
and ....
and t.rowid = :block.rowid
FOR UPDATE NOWAIT;
if that returns ORA-54 (resource busy), you are notified someone else has that
row locked.
if that returns 0 rows, you are told that the data has been modified
-- you need
to requery
if that returns 1 row, you have the row locked and will be able to
delete it and
no one else can touch it."
END OF QUOTE
Do we have to customize the Form widget or write the SELECT FOR UPDATE
explicitly?
Or does the framework already contemplates this cases?
Thanks,
Alex
On 12/2/06, Fabian Gorsler <[EMAIL PROTECTED]> wrote:
Hi Alexandre,
perhaps you should specify your problem. Is there actually a problem or
are you just asking to prevent a possible problem?
You can specify the isolation level for the DB connection in your
framework/entity/config/entityengine.xml per data source.
Best regards,
Fabian.
