Ed,
I answered your message privately, let's take this discussion off line.
Thanks and bye.
Flavio
"Ed Prochak" <edprochak_at_adelphia.net> wrote in message
news:3E67BC26.7070508_at_adelphia.net...
> FC wrote:
> > "Billy Verreynne" <vslabs_at_onwe.co.za> wrote in message
> > news:b475qk$k8t$1_at_ctb-nnrp2.saix.net...
> >
> >
> >>Or am I missing your point totally?
> >>
> >
> >
> > I think you missed the point, you stated exactly the contrary of my
> > intentions, please read the message again.
> >
> > I am looking for a method of knowing whether a certain user has got any
> > pending updates, other than using the usual "Has anything changed" flag
at
> > the client side and I thought it could be done via a query.
> > I am just asking whether you think it is feasible or not, no more, no
less.
> >
> > Thanks and bye,
> > Flavio
>
>
>
>
> It is still unclear to us what you really are trying to save. If your user
> hits the UNDO button, you issue a rollback and ORACLE cleans up.
>
> Lets see, here was your original post:
> > Hello Oraclers,
> > I was asking myself what are the possible drawbacks of the following
> > approach:
> >
> > I've some client front-ends modifying data by means of stored procedures
and
> > they are allowed to change several values on different tables before
> > committing or rolling back.
> > Instead of maintaining a flag indicating whether something has changed
on
> > the client, I was wondering about the possibility of evaluating a
function
> > or alike that checks for any pending locks (via V$LOCKED_OBJECT
presumably)
> > against its session id.
> >
> > Any thoughts about this?
>
> And your second post said:
> >
> > Well, each user is updating his own stuff, so this is one of those lucky
> > situations where I am 100% sure there are no concurrent changes to the
same
> > record.
> > Volumes of data are very low, so performance is not an issue, I just
want to
> > give a quick "undo" possibility to the user without having to check
table by
> > table and record by record what he has changed.
> > If I don't allow rollbacks at the db level, then I must write my own
> > rollback at the client level, which violates the first law of the good
> > programmer: do not reinvent the wheel.
> > So, in the end, since I do not need to check for selects of other users,
is
> > there any other strong objection for not querying v$locked_object?
>
>
>
>
> Let me see if I can rephrase this.
>
> You want to avoid having a "data changed" flag on the client application.
> Instead you want to check if there are any pending changes in the DB.
> Presumably these are from invoking one or more of your stored procedures.
> Specifically you think you will get your answer by querying the locks.
> And then with the information you can perform a "quick UNDO". I guess this
> means WHAT exactly, since "performance is not an issue".
>
> My thoughts are that checking the locks seems like the long way around.
When
> the UNDO button is clicked, doesn't the client just have to:
> issue a ROLLBACK
> fetch the current records again
> ?
>
> Okay the rollback may close cursors, so you have to reopen them and start
from
> there. I still do not see why you have any interest in checking locks.
>
> Ed "puzzled" Prochak
>
> --
> Ed Prochak
> running: http://www.faqs.org/faqs/running-faq/
> family: http://web.magicinterface.com/~collins
> --
> "Two roads diverged in a wood and I
> I took the one less travelled by
> and that has made all the difference."
> robert frost
>
Received on Thu Mar 06 2003 - 17:46:35 CST
