Hi!
That's not the right way to do this. Don't forget that, at EO
level, you don't even know what are tables... worst, you may not lock
them (unless writing SQL code directly, but that is NOT EO at all!).
You should solve that at the DB level, with stored procedures,
constraints, etc etc.
yours
Miguel Arroz
On 2006/02/06, at 15:45, Guido Neitzer wrote:
On 06.02.2006, at 16:36 Uhr, Gino Pacitti wrote:
What about the holding of a value in a table and doing a raw row
fetch and if on committal there is a conflict alert user to change?
I haven't done this. but what about a single table for that and
lock the table (or the row) for a complete transaction of reading
the current value, incrementing it and writing back the new number.
So you won't need a handling for optimistic locking failures and
everything is wrapped in a single SQL transaction. But perhaps it
may block your applications in timeouts, if there is a lot of
concurrent traffic for this feature ...
cug
--
PharmaLine, Essen, GERMANY
Software and Database Development
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/arroz%
40guiamac.com
This email sent to [EMAIL PROTECTED]
"I felt like putting a bullet between
the eyes of every Panda that wouldn't
scr*w to save its species." -- Fight Club
Miguel Arroz
http://www.ipragma.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
