Subject | Re: [firebird-support] MySQL Migration Trigger Issue |
---|---|
Author | Helen Borrie |
Post date | 2007-03-30T08:26:23Z |
At 06:12 PM 30/03/2007, you wrote:
unless the DML operation itself is committed. If the DML operation
is rolled back, instead of being committed, all of the stuff that
your trigger did to the other table is also rolled back.
You don't "commit triggers". Committing is something you do to a transaction.
client-side thing, where the client application requests a "post
action" to be followed immediately by a commit. Some ODBC drivers
provide this, perhaps that is what you are referring to.
But no sort of commit, "auto" or otherwise, will happen at all if an
exception occurs. The whole transaction will be left in a state
where the client application has to decide what to do about
it. Maybe the driver has some kind of "auto-rollback" action too. :-)
./heLen
>Thanks for the explanation, Helen.Hmmm, perhaps you don't understand that trigger actions don't "stick"
>
>Is there a way to auto-commit the trigger?
unless the DML operation itself is committed. If the DML operation
is rolled back, instead of being committed, all of the stuff that
your trigger did to the other table is also rolled back.
You don't "commit triggers". Committing is something you do to a transaction.
>The insert (into data) is coming through an ODBCIt's impossible to get a dirty read in Firebird. "Auto-commit" is a
>connection and appears to auto-commit (or I'm getting
>a really good dirty read across several hundred rows).
client-side thing, where the client application requests a "post
action" to be followed immediately by a commit. Some ODBC drivers
provide this, perhaps that is what you are referring to.
But no sort of commit, "auto" or otherwise, will happen at all if an
exception occurs. The whole transaction will be left in a state
where the client application has to decide what to do about
it. Maybe the driver has some kind of "auto-rollback" action too. :-)
./heLen