On Tuesday 10 September 2002 07:46 pm, scott.marlowe wrote:
> On Tue, 10 Sep 2002, Stephan Szabo wrote:
> > > > > > It starts a transaction, failes the first command and goes into
> > > > > > the error has occurred in this transaction state. Seems like
> > > > > > reasonable behavior.
> > > > >
> > > > > Select command don't start transaction - it is not good
> > > >
> > > > I think you need more justification than "it is not good." If I do a
> > > > sequence of select statements in autocommit=false, I'd expect the
> > > > same consistancy as if I'd done
> > > > begin;
> > > > select ...;
> > > > select ...;
> > >
> > > Ok.You start transaction explicit and this is ok.
> > > But simple SELECT don't start transaction.
> >
> > Actually someone post a bit from Date's book that implies it does.
> > And, that's still not an justification, it's just a restating of same
> > position. I don't see any reason why the two should be different from
> > a data consistency standpoint, there might be one, but you haven't
> > given any reasons.
>
> What if it's a select for update? IF that failed because of a timout on a
> lock, shouldn't the transaction fail? Or a select into? Either of those
> should make a transaction fail, and they're just selects.
Ok.Any lock or update,delete, insert (and all ddl command) start transaction
(select for update, too), but simple select no.Select don't change data and no
transaction - this process cannot lost consistency (any command with error
too).
And if transaction start, so what ... I will (maybe) continue transaction
(I don't end transaction), but I get error. and I must end transaction
I think that we must parse command, choose if 'start transaction' and start
transaction or no.
regards
Haris Peco