[
By the way: how about a pointer to the new list in this auto-response and
a link on http://lists.cpan.org/.
Subject: Auto-response for your message to the "Dbdpg-general" mailing list
This mail list is now defunct. Please send messages to
[EMAIL PROTECTED], instead.
]
I'm not clear what the intended behavior is suppose to be. But it
seems that changing AutoCommit from 1 to 0 should issue a BEGIN, and
from 0 to 1 a COMMIT from the docs below.
Could someone clarify?
In testing changing AutoCommit does not issue and BEGIN or COMMIT.
DBI says:
"AutoCommit" (boolean)
[...]
* Databases in which a transaction is always active
(not Pg by referenced by the next section)
These are typically mainstream commercial relational databases with
"ANSI standard" transaction behaviour. If "AutoCommit" is off, then
changes to the database won't have any lasting effect unless "commit"
is called (but see also "disconnect"). If "rollback" is called then
any changes since the last commit are undone.
If "AutoCommit" is on, then the effect is the same as if the DBI
called "commit" automatically after every successful database opera-
tion. So calling "commit" or "rollback" explicitly while "AutoCommit"
is on would be ineffective because the changes would have already
been commited.
> Changing "AutoCommit" from off to on will trigger a "commit".
For databases which don't support a specific auto-commit mode, the
driver has to commit each statement automatically using an explicit
"COMMIT" after it completes successfully (and roll it back using an
explicit "ROLLBACK" if it fails). The error information reported to
the application will correspond to the statement which was executed,
unless it succeeded and the commit or rollback failed.
* Databases in which a transaction must be explicitly started
For these databases, the intention is to have them act like databases
in which a transaction is always active (as described above).
> To do this, the driver will automatically begin an explicit transac-
> tion when "AutoCommit" is turned off, or after a "commit" or "roll-
> back" (or when the application issues the next database operation
> after one of those events).
In this way, the application does not have to treat these databases
as a special case.
--
Bill Moseley
[EMAIL PROTECTED]
