Plötzlicher Fehler in DB-Abfrage (Perl, DBI) (Datenbanken und Verzeichnisdienste)

[thread]3540[/thread]

Plötzlicher Fehler in DB-Abfrage (Perl, DBI)

Gast Gast

2005-02-19 18:02

Hi Ihr,

ich habe meine Datenbank-Routine 1000x auf 1000 Servern benutzt und immer hat es funktioniert.

Plötzlich funktioniert das Ganze auf einem Server nicht mehr. So sieht das Ganze aus:

Code: (dl )

sub datenbank
{
   use DBI;
   my $dbh = DBI->connect("DBI:mysql:dbname:localhost:3306", "user", "pass", { PrintError => 0, RaiseError => 0 } )  or die "Daten falsch";
   $sth = $dbh->prepare($anfrage) or die "Anfrage falsch";
   $sth->execute();
}

Aufrufen tue ich das Ganze immer mit:

$anfrage = "SELECT ....";
&datenbank;

GeDIEt wird immer mit der "Daten falsch"-Meldung. Die Daten sind aber nachweislich 100%ig richtig.

Woran kann das Ganze liegen?

Wäre über Hilfe sehr dankbar.

LG
Steffen

GwenDragon

2005-02-19 18:58

User since
2005-01-17
14555 Artikel
Admin1

Was steht denn in $DBI::errstr als Fehler?

die Drachin, Gwendolyn

Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel

steffenw

2005-02-19 21:11

User since
2003-08-15
692 Artikel
BenutzerIn

genau, wie's @GweenDragon sagt. Wenn Du im Fehlerfall sowieso die aufrufst, kannst Du auch gleich RaiseError auf 1 setzen, denn Du hast bis jetzt keine Fehlerbehandlung bei prepare und execute drin. Und die sind sehr wohl fehleranfällig, auch die fetchrow...-Methoden laufen nie komlett fehlerfrei, denn was passiert, wenn die Verbindung zur Datenbank abbricht, dann sollte Dein Programm nicht dem Glauben verfallen, es wären keine oder nur wenige Daten verfügbar.

$SIG{USER} = sub {love 'Perl' or die};

GwenDragon

2005-02-20 09:44

User since
2005-01-17
14555 Artikel
Admin1

Am Besten und professionell ist es, eine Transaktion zu starten, die DB-Abfragen in eval zu setzen und bei Fehlern die Transaktion rückgängig zu machen.

die Drachin, Gwendolyn

Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel

Taulmarill

2005-02-20 13:28

User since
2004-02-19
1750 Artikel
BenutzerIn

user image

warum sollte man die abfregen in ein eval setzen?
wenn man bei einer datenbank transaktionen benutzt, sollte man auch die fehlerbehandlung der datenbank überlassen. z.B. sollte die datenbank selbst im fehlerfall die transaktion rückgängig machen.

$_=unpack"B*",~pack"H*",$_ and y&1|0& |#&&print"$_\n"for@.=qw BFA2F7C39139F45F78 0A28104594444504400 0A2F107D54447DE7800 0A2110453444450500 73CF1045138445F4800 0 F3EF2044E3D17DE 8A08A0451412411 F3CF207DF41C79E 820A20451412414 83E93C4513D17D2B

steffenw

2005-02-20 13:52

User since
2003-08-15
692 Artikel
BenutzerIn

Genau, es fehlt der 3 Parameter beim connect, der da ist:

Code: (dl )

AutoCommit => 1

Zur Zeit macht das DBI defaultmäßig aber man soll sich wegen zukünftigen Versionen nicht darauf verlassen. Wenn die Datenbank keine Transaktionen unterstützt, geht das connect mit Autocommit => 0 in die Hose.

Das Eval bringt nichts, wenn man danach auch nur

Code: (dl )

$@ and die $@;

macht. Will man am Ende nur korrekt aufräumen ist

Code: (dl )

my $dbh;   # Deklaration
END {
  for ($dbh) {
    $_ and eval{$_->disconnect};
  }
}
$dbh = DBI->connect(....);

die bessere Variante, als im Programm jedes $dbh einzeln aufzuräumen.\n\n

$SIG{USER} = sub {love 'Perl' or die};

Strat

2005-02-21 00:18

User since
2003-08-04
5246 Artikel
ModeratorIn

ich finde, es bringt absolut nichts, prepare/execute/... in eval zu setzen; sowas braucht man hoechstens, wenn man beim connect mit RaiseError => 1 arbeitet... Wenn man jedoch auf RaiseError => 1 verzichtet, kann man da wunderbar den Returncode abfragen, und man bekommt mit $dbh/$sth->errstr oder $DBI::errstr wunderschoene Fehlermeldungen... oder mit ->err auch was numerisches... und das ist einem eval in Kombination mit RaiseError => 1 wohl um einiges ueberlegen...

Und auch beim disconnect reicht i.d.R.
ref($dbh) and $dbh->disconnect(); ...\n\n

perl -le "s::*erlco'unaty.'.dk':e,y;*kn:ai;penmic;;print"
http://www.fabiani.net/

View all threads created 2005-02-19 18:02.