Zum Schluss noch ein paar Worte zur Fehlersuche in solchen Skripten. Eine erste Maßnahme ist bereits das Einschalten des Warnmodus
»-w
«
von Perl, was dazu führt, dass sich der Interpreter über Sachen beklagt, die ihm komisch vorkommen. Auch
»use strict;
«
sollte selbstverständlich sein, damit man nicht über triviale Patzer wie verschriebene Variablennamen stolpert. Ansonsten beugt der oben schon erwähnte DBI-Parameter
»RaiseError()
«
wirksam vor, indem er automatisch den Rückgabewert jedes DBI-Methodenaufrufs checkt und das Skript beendet, wenn etwas schiefgelaufen ist. Die nächste gute Quelle für Hinweise auf Probleme ist das Error-Log der Datenbank (soweit beteiligt auch das des Webservers). Zur Laufzeit konstruierte SQL-Abfragen kann man zu Testzwecken vorher auch mit
»print
«
ausgeben. Allerdings funktioniert das nicht mehr, wenn sie Platzhalter verwenden. In diesem Fall muss man das Tracing des DBI-Moduls einschalten, um zu sehen, was es tatsächlich an die Datenbank übermittelt. Nötig ist mindestens der Trace Level 2. Einstellen kann man ihn auf zweierlei Weise: entweder über ein Handle
$sth->{TraceLevel}=2;
oder über eine Environment-Variable:
DBI_TRACE=2=dbitrace.log export DBI_TRACE
In letzterem Fall kann man auch eine Log-Datei an beliebigem Ort mit angeben. Andernfalls landen alle Ausgaben wie auch im Fall der Konfiguration über das Handle auf StdOut.