Re: newbee ROLLBACK/ COMMIT

AHH!
this explains a lot,

esp. why I keep getting record in use messages from the remote view in foxpro.

yes I'm client server
I have the procedures on the oracle server then pass parameters from foxpro, to update the tables.

so how do I enable dead client detection.

also you explain that I can see the row if I select it back, then further down you say it will not appear in a select. do you mean I have to use a unique key field to get it.

steve

Thomas Kyte <tkyte_at_us.oracle.com> wrote:

> A copy of this was sent to spectre_at_hkstar.com (Steve A)
> (if that email address didn't require changing)
> On Wed, 11 Aug 1999 18:25:31 +0800, you wrote:
>
> >Hi,
> >I'm a bit confused by the rollback command, I understand the function of
> >commit ,rollback & savepoint
> >
> >But have the following questions.
> >1. do I have to use the savepoint command?
>
> no
>
> >2. if my client crashes during the transaction , how long does the "temp
> >changes" sit around or is it dropped when I crash
> >
>
> depends on the circumstances. if you are client server, and you do not have
> dead client detection enabled, it may sit around until you manually kill the
> session or restart the database.
>
> >3. if my client crashes, then re-logs in & then re-does the work and
> >commits , will the server throw away the old crashed session or try to
> >commit it when I issue a commit in a new session.
> >
>
> the 2 sessions are mutually exclusive of each other - they have nothing
> whatsoever to do with each other. if you client crashes and the server can
> detect it -- it'll be rolled back and cleaned up (dead client detection).
  OTOH
> -- if the server cannot detect it, any outstanding locks gathered by that
> session (the crashed one) will stay in place.
>
> when your client logs back in -- they may not be able to redo the work YET
 since
> the crashed session may still be there.
>
>
> >4. can anybody see any "temp" changes made to the database (including
> >my client) before the commit has been issued.
> >
>
> you can see your changes -- if you insert a row and select it back it, you'll
> see it. No one else will until you commit.
>
> You can see your changes.
> No one else can.
>
> The statement that makes a change cannot 'see' its own changes. For example:
>
> insert into T select * from T;
>
> The select * from T will not (fortunately) "see" any of the new rows being
> inserted into T. The select will see T as it was BEFORE the insert started
> (otherwise that would be an easy way to write an infinite loop)...
>
>
> >5. how long between the commit & the changes becomming visible in the
> >database
> >
>
> immediate -- you commit, they are there.
>
> >steve
> >
Received on Wed Aug 11 1999 - 18:49:32 CDT