Re: Commiting changes [Was: Re: What is the meaning of the "rows" value after a select?
On Sat, Dec 06, 2008 at 07:41:24AM -0800, Jonathan Leffler wrote:
> >
> > The situation doesn't come up frequently, so I am just wanting to find
> > out what DBI is going to do when it does. I checked the logs of the
> > program and for every delete that the program reports that it
> > attempted, those records are no longer present in the database. So I
> > am trying to get a clearer understanding of what is going on in this
> > case.
>
> DBI disconnects. What the DBMS does depends on the DBMS.
>
> I believe Oracle commits; Informix definitely rolls back incomplete
> transactions.
For drivers using the Driver.xst 'driver interface template' (which
includes DBD::Oracle), rollback() is automatcally called just before the
handle is DESTROYd. I've appended the relevant code.
Tim.
if (DBIc_ACTIVE(imp_dbh)) {
if (!DBIc_has(imp_dbh,DBIcf_AutoCommit)) {
/* Application is using transactions and hasn't explicitly
disconnected.
Some databases will automatically commit on graceful
disconnect.
Since we're about to gracefully disconnect as part of the
DESTROY
we want to be sure we're not about to implicitly commit
changes
that are incomplete and should be rolled back. (The DESTROY
may
be due to a RaiseError, for example.) So we rollback here.
This will be harmless if the application has issued a
commit,
XXX Could add an attribute flag to indicate that the driver
doesn't have this problem. Patches welcome.
XXX or could just move the DBIc_is(imp_dbh, DBIcf_Executed)
test
to cover the rollback as well. That just needs sanity
checking
that DBIcf_Executed is set by any/all possible way to
execute a
statement that might start a transaction.
*/
if (DBIc_WARN(imp_dbh)
&& DBIc_is(imp_dbh, DBIcf_Executed) /* has not just called
commit/rollback */
&& (!dirty || DBIc_DBISTATE(imp_dbh)->debug >= 3)
)
warn("Issuing rollback() for database handle being
DESTROY'd without explicit disconnect()");
dbd_db_rollback(dbh, imp_dbh); /* ROLLBACK! */
}
dbd_db_disconnect(dbh, imp_dbh);
Re: Commiting changes [Was: Re: What is the meaning of the "rows" value after a select?
On Fri, Dec 5, 2008 at 7:12 AM, Larry W. Virden <[EMAIL PROTECTED]> wrote:
> On Dec 1, 10:54 am, [EMAIL PROTECTED] (Larry W. Virden) wrote:
> > I inherited some perl code that mostly works, but which I've a couple
> > questions about what it is doing.
> >
> > Skipping miscellaneous comments, etc. the code sets some variables
> > from a file, sets its oracle environment, and then does the following:
> > $oraProdDBH = DBI->connect("dbi:Oracle:", $user_name, $password)
> > or die "Failed to connect to $DBI:errstr\n";
> > $oraProdDBH->{RaiseError} = 1;
> > $oraProdDBH->{AutoCommit} = 0;
>
>
> Earlier I mentioned the above in the thread about understanding the
> "rows" variable. Today, as I am studying the code, I have a question
> about this line about AutoCommit.
>
> If I understand that right, that should mean that an explicit commit
> is needed for any action taken by the handle?
>
Because AutoCommit is set to zero (off), you need to manually commit
transactions.
>
> Later in the code, a SQL DELETE statement is done using that handle,
> and, afterwards, all I see is a
> $oraProdDBH->disconnect statement.
>
> The situation doesn't come up frequently, so I am just wanting to find
> out what DBI is going to do when it does. I checked the logs of the
> program and for every delete that the program reports that it
> attempted, those records are no longer present in the database. So I
> am trying to get a clearer understanding of what is going on in this
> case.
>
DBI disconnects. What the DBMS does depends on the DBMS.
I believe Oracle commits; Informix definitely rolls back incomplete
transactions.
--
Jonathan Leffler <[EMAIL PROTECTED]> #include
Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."
Commiting changes [Was: Re: What is the meaning of the "rows" value after a select?
On Dec 1, 10:54 am, [EMAIL PROTECTED] (Larry W. Virden) wrote:
> I inherited some perl code that mostly works, but which I've a couple
> questions about what it is doing.
>
> Skipping miscellaneous comments, etc. the code sets some variables
> from a file, sets its oracle environment, and then does the following:
> $oraProdDBH = DBI->connect("dbi:Oracle:", $user_name, $password)
> or die "Failed to connect to $DBI:errstr\n";
> $oraProdDBH->{RaiseError} = 1;
> $oraProdDBH->{AutoCommit} = 0;
Earlier I mentioned the above in the thread about understanding the
"rows" variable. Today, as I am studying the code, I have a question
about this line about AutoCommit.
If I understand that right, that should mean that an explicit commit
is needed for any action taken by the handle?
Later in the code, a SQL DELETE statement is done using that handle,
and, afterwards, all I see is a
$oraProdDBH->disconnect statement.
The situation doesn't come up frequently, so I am just wanting to find
out what DBI is going to do when it does. I checked the logs of the
program and for every delete that the program reports that it
attempted, those records are no longer present in the database. So I
am trying to get a clearer understanding of what is going on in this
case.
Thank you again for your patience.
