in reply to $dbh->prepare not triggering die

I believe that the prepare is probably always returning true (from the documentation). You might want to move the or die statement from the prepare line to the execute line. The docs say:

Drivers for engines without the concept of preparing a statement will typically just store the statement in the returned handle and process it when $sth->execute is called,

You might want to read the documentation under Database Handle Methods for further info.

-enlil

Replies are listed 'Best First'.
Re: $dbh->prepare not triggering die
by Abigail-II (Bishop) on Dec 02, 2002 at 10:05 UTC
    What I usually do is: 
        my $dbh = DBI -> connect ("DBI:$driver:database=$db;host=$host",
                              $user, $password,
                              {RaiseError => 1, PrintError => 0,
                               AutoCommit => 0, Taint      => 1})
              or die "Failed to connect: $DBI:errstr\n";
 
    ...

    eval {
        my $sth = $dbh -> prepare ($cmd);
        $dbh -> execute (@variables);
        while (my @row = $dbh -> fetchrow_array) {
            ... process @row ...
        }
        $dbh -> commit;
    };
    if ($@) {
        $dbh -> rollback;
        croak "Database query failed: $@";
    }

    [download]

    Abigail

[reply]
[d/l]
      This methodology works well with larger database such as Oracle or SQL Server. However the normally distributed version of mysql does not have transactional support :( which makes things more difficult as rollback and commit are just no-op functions. mysqlmax and the commercial versions do have transactional support but not many people use them.

      Transactional support is a whole new ball game especially when you need multiple sub-procedures with an error in any of them causing a rollback. I tend to move the transaction start and transaction commit/rollback into a sub-procedures on their own to handle this.

      Hope it helps
      UnderMine

[reply]
        Really? Odd, I lifted that code from a project I'm currently working on, and that does use MySQL. Not my choice, as MySQL isn't much of a database, but newer versions do support transactions - use the InnoDB type of tables.

        Why anyone would bother using a database that doesn't support transactions is beyond me. It just doesn't make any sense.

        Abigail

[reply]
[d/l]

        Well what the heck! What good is a database when it doesn't support transactions? This is a divergence from the original question but why on earth doesn't the stock MySQL do transactions by default? That's just... you might as well be using a really fast DBD::CSV or something then for all the help it's giving you. I mean c'mon - this is one of the reasons why you step up to RDBMS in the first place. If that's isn't a deliberately crippled install then I just don't get it (which might actually be true).

        __SIG__
use B;
printf "You are here %08x\n", unpack "L!", unpack "P4", pack
  "L!", B::svref_2object(sub{})->OUTSIDE;

        [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom