Re: difficult query (returning into) ???

From: Roy <something_at_something.here>
Date: Fri, 9 Nov 2001 15:59:51 +0100
Message-ID: <9sgr0q$228$1_at_news1.xs4all.nl>


> >
> I think you should first study what a transaction is and what locking
> can do for you. Or you should search in the archives at
> groups.google.com the answer to a similar question outlining the
> difference between optimistic and pessimistic locking.
> These are not mind-breakers, these are attempts to drive directly to
> hell.
> I also think you would be way better off by building your applications
> with Designer, doing so they will be 200 percent more robust than what
> you are doing now.
>
I think you refer to my 'first' question: Using designer doesn't solve this... even Oracle 'experts' over here don't have a solution......even worse.... I think no database supports real state-less transactions in a multi-user environment.

When two users can 'ask' for the same data at the same time and both can change it, no locking (either pessimistic nor optimistic) can help. There is no active connection from a webbrowser with the database (web-and application servers are between them)... you don't want to lock because you don't know what a user wants to do (perhaps he retrieves data and goes away for a cup of coffee or a meeting) , but sometimes a user does change a record....to lock at the latest possible moment is (imho) the wisest thing to do.... but what if the second user also changes the same record....well hell breaks loose.....again imho the only thing you can do then is inform the second user that data on his screen is old and has changed and do a refetch....again Designer won't solve this one for you.

My second question is already solved by 'our experts' (sorry for asking).....just write a function
so something like this
update data-table
set data-table.field='value'
where data-table.key = uniquenumber
returning data-table.field, data-table.status, function_to_get_description(data-table.status) into :var1, :var2, :var3 Received on Fri Nov 09 2001 - 15:59:51 CET

Original text of this message