I'm fairly certain Oracle Forms does this too. I've had to write
some complex forms that worked on updateable views, and I
had to re-write Forms' on-update and on-lock triggers myself.
yosi
[EMAIL PROTECTED] wrote:
> Not so weird, PeopleSoft does things in a similar manner. When a panel
> in
Thanks to everybody who replied. We already have a solution similar to this
implemented (via triggers) which allows us to not re-query the databse
before doing an update, since the fields we are interested in are spread
across multiple tables, etc., etc. I also realize that there multiple ways
John,
we are using ADO, VB and ASP pages for our application.
all transactions are stateless, much the same way you are explaining your
system.
To ensure that an update can occur with a high degree of confidence that the
record did not change, we do the following:
Every database table has a "
>For whatever reasons this solutions was found to be not sound by a 3rd
>party "consulting" company which reccommended "Oracle native technology"
>to perform this check.
Hmm... a trigger seem native to me. Perhaps they meant auditing.
-Original Message-
[mailto:[EMAIL PROTECTED]]
Sent: T
Oracle Forms achieves this (under its optimistic
locking mode) by:
After selecting the data (for display), when an update
is to occur it re-select's using the rowid for the row
to be update and also checks if the columns are still
the same values as the what it originally selected.
If not, then
