Re: archiving records

Michel Cadot wrote:
> "Daud" <daud11_at_hotmail.com> a écrit dans le message de news: 1156821506.859600.301660_at_74g2000cwt.googlegroups.com...
>
> Michel Cadot wrote:
> > "Daud" <daud11_at_hotmail.com> a écrit dans le message de news: 1156760226.440981.312160_at_i42g2000cwa.googlegroups.com...
> > | >
> > | > Yes, *exactly*, 'assume'! *NO* guarantee whatsoever
> > | > as
> > | > a) you don't lock the table
> > | > b) you break up your *logical* transaction into multiple *physical*
> > | > transactions
> > | > Basic violations against the ACID concept.
> > | >
> > | > Please do not top post.
> > | >
> > |
> > | What do you mean? I don't understand. Why the table has to be locked?
> > | Those rows with colA = 'ABC' will not be updated. No rows with
> > | colA='ABC' will be inserted. So, why lock the whole table?
> > |
> >
> > What Sybrand said is unless you are alone on the database
> > you cannot guarantee a correct result with your procedure.
>
> Hi Michel,
>
> Thanks for your reply. So, if I am "alone", I will always get a correct
> result with the procedure above (modified procedure in my second post)?
> If you read my assumptions, it is like I am "alone" when the procedure
> is executed.
> I understand that there is no ordering/sequence when retrieving rows
> from a table (unless you use ordery by clause).
>
> Daud
>
> ---------------------------------------------------------------
>
> The only way to make sure your assumptions are true is to lock the table.
> And we are back to Sybrand answer.

With Oracle you are never alone. Even with table locking, might a delayed block cleanout set off by the select possibly give a different row set than the delete? Repeatable reads are not guaranteed across statements by default.

jg

--
@home.com is bogus.
http://www.duckproducts.com/creative/default.asp?usecat=4