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 <disclaimer.h>
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."
