Informix: Entwickeln leicht gemacht

Debuggen von Stored Procedures und Vergleichen von Objekten

Abb. 1: AGS hat vor kurzem eine neue Version (3.5.12) des Server Studio herausgebracht.

Ob man noch etwas für Informix entwickeln soll oder nicht? Diese Frage wird hier nicht beantwortet. IBM behauptet „ja“. Also wird DB2 vielleicht doch noch eingestampft? Auf jeden Fall hat Advanced Global Systems (AGS) - wir berichteten in der News 02/2001 - eine neue Version des Server Studio (s. Abb. 1) herausgebracht und Informix (oder besser IBM?) setzt auch „auf dieses Pferd“, wie man an der Webseite www.serverstudio.com erkennen kann. Wir widmen uns in diesem Artikel ganz dem Thema „Debugging von Stored Procedures“.

Trace On/Trace off?

Die meisten unter Ihnen werden vermutlich „Debuggen“ oder Fehlersuchen in Informix Stored Procedures bisher mittels der Trace Eigenschaft und des Debug Files erledigt haben. Bei mehreren sich aufrufenden Prozeduren ist dies eher nicht zu empfehlen.

Abb. 2: Start einer Debug Session für eine Prozedur: Die Argumente für die Prozedur bleiben erhalten ...

Also gehen wir dieses Mal den Weg, den uns AGS mit dem Server Studio empfiehlt. Wir debuggen aus dem Server Studio heraus. Wichtig ist hierbei, dass man das Repository eingeschaltet hat. Um das Debugging von mehreren sich aufrufenden Prozeduren zu ermöglichen, muss für jede der Prozeduren, die tatsächlich ge’debugged‘ werden soll, vorher die sogenannte Debug Version der Prozedur angelegt werden.

Anlegen der Debug Version

Wie das geht? Im Object Browser die gewünschte Prozedur selektieren, die rechte Maustaste klicken (für Gegner der Maus geht das auch über eine Windows-konforme Tastatur), die „Debug Version“ anwählen und schon verändert sich das Icon der Stored Procedure.

Klickt man erneut die rechte Maustaste, hat sich das Menü verändert und man kann jetzt „Debug“ anwählen.

Das Debug Fenster

„Fensterln“ wird nicht nur in Bayern groß geschrieben, sondern auch bei AGS. Kaum hat man - wie oben beschrieben - „Debug“ ausgewählt, geht ein Fenster auf (s. Abb. 5). Viergeteilt - sozusagen „mit Fensterkreuz“ und hinter jeder „Scheibe“ verbergen sich andere Informationen. Drei der Teilbereiche (s. Abb. 5, 7, 8) verfügen über zusätzliche Reiter.

Abb. 3: ... bzw. wenn man auf “Save As” drückt, kann man diese ... (s. Abb. 4)

Im linken oberen Fenster finden Sie den Source Code und das Fenster, in dem man sich z. B. schrittweise fortbewegt, Breakpoints definiert usw. Rechts oben kann man den Source Browser (dieser sieht fast wie der Object Browser aus, enthält jedoch nur Trigger und Stored Procedures), die Breakpoints (alle, die es gibt!) und die Break Historie anzeigen und bearbeiten. Bearbeiten heißt z. B. für zusätzliche Prozeduren „debuggen“ ein-/auszuschalten oder Breakpoints zu „enablen/disablen“.

Abb. 4: ... in einer “PRM” Datei abspeichern.

Links unten werden die lokalen Variablen (1. Reiter), die globalen Variablen (2. Reiter) und die Aufrufparameter (3. Reiter) mit den jeweiligen Werten angezeigt.

Der vierte Teil des Fensters dient dazu, bestimmte Variablen zu beobachten. Der zugehörige Reiter heißt „Watch“. Über den Reiter „Messages“ lassen sich die Meldungen anzeigen.

Bevor es los geht

Natürlich hatte ich etwas unterschlagen. Bevor es mit den vier „Scheiben“ so richtig losgeht, muss man noch eine Maske ausfüllen, was sich aber als äußerst praktisch herausstellt (s. Abb. 2 und 3). Damit man nicht immer wieder den Aufruf erneut via SQL eintippen muss und damit man direkt aus einer Applikation debuggen kann, werden die Parameter festgelegt. Diese können auch in einer *.PRM Datei abgespeichert werden (s. Abb. 3 und 4).

Darin stehen der Objekt-Name und -Typ, sowie die Parameter, Parameter für das Repository und die Repository-Tabellen.

Und jetzt debuggen wir ...

Alles einmal ausgefüllt, wird diese Datei beim Start wieder herangezogen und man kann (Regressionstest!) immer wieder identisch loslegen. Zum Starten kann man F3 drücken, über Menü (Debug ® Start Debug Session) oder auch über die Symbolleiste gehen. In unserem Debug Fenster wird die erste (ausführbare) Zeile der Stored Procedure gelb unterlegt, gleichzeitig erscheint links davon ein Pfeil.

Abb. 5: Das viergeteilte Debug Fenster. Drei der Fenster besitzen unterschiedliche Reiter.

Richtig los geht es aber erst, wenn man F10 (Schrittweise) oder F5 (Run) drückt. Die Bedienung kann auch per Maus über die Symbolleiste oder das Menü erfolgen. „Run“ lässt einen bis zum nächsten Breakpoint laufen, bis zum ersten Fehler oder komplett durch. Mit dem schrittweisen Vorgehen kommt man befehlsweise vorwärts und mit „Step into“ (F11) stoppt man u. a. jedes Mal am Beginn einer Stored Procedure.

Hat man „Run“ gewählt und bleibt selbst bei Breakpoints nicht stehen (z. B. weil man sie nicht erreicht), so kann man „Break“ wählen. Hoppla - dafür gibt es keine Funktionstaste!

Was ist mit Fehlern?

Abb. 6: Wer “dumme” Fehler macht, bekommt diese sehr schnell heraus.

Trifft man auf Fehler (s. Abb. 6 oder 7), so wird der Ablauf unterbrochen. Es öffnet sich ein Fenster, das man erst bestätigen muss, bevor es weitergeht. Das hilft schneller weiter, als eine Prozedur auszuführen, den Trace zu analysieren und aufgrund dessen (man weiß z. B. nicht, was die Variablen-Inhalte sind) herauszufinden, was schief gelaufen ist.

In unserem Beispiel wurden einfache Fehler (s. Abb. 6), aber auch sehr problematische Teile (s. Abb. 7) sehr schnell herausgefunden, ohne die Datenbank wieder zurücksetzen zu müssen!

Abb. 7: Auch bei nicht ganz so dummen Fehlern ist man besser bedient als mit “dbaccess”.

Achtung

Natürlich muss man auch ein wenig aufpassen. Also nicht einfach parallel aus einem (alten) SQL Editor (oder gar ausserhalb des Server Studios) DROP und CREATE einer Prozedur ausführen. Die Debugged Version wird im Repository gehalten und da kommt das Server Studio verständlicherweise durcheinander. Also: Debug Session schließen, editieren, neu anlegen (geht auch wirklich einfach und schnell), Debug starten und los geht es (bis zum nächsten Fehler).

Wenn es läuft ...

... dann freut man sich und kann z. B. im Watch Fenster die Veränderung der Variablen begutachten (s. Abb. 8) und hoffentlich am Ende des Vorgangs die Abb. 9 erwarten.

Abb. 8: Und wenn es läuft, hat man seine helle Freude daran: Break History, zu beobachtende Werte (global, lokal) ...

Abb. 9: Fein, dass alles läuft!

Source Vergleiche

Fein, dann ist man also fertig, kann alles schließen und nach Hause gehen? Halt, natürlich hat man in einer Testdatenbank getestet und da könnte doch die Stored Procedure oder eine Tabelle unterschiedlich sein? Aber man weiß leider nicht mehr tatsächlich, ob die Objekte vorhanden sind - und wenn ja, in welchem Zustand sie sind. Also einmal nachgeguckt und siehe da: die Tabellen sind schon da, unsere Stored Procedure auch. Schön aber sind sie identisch?

Abb. 10: Vergleich der Inhalte zweier SQL-Editor-Fenster. Über den SELECT Button geht es zurück zur Auswahl.

Sicherheitshalber startet man den Vergleich zwischen Objekten. Dabei kann man Prozeduren in zwei Datenbanken (ja sogar Servern) vergleichen, SQL Files und SQL Editor Inhalte. Letzteres wählt man, um z. B. die Tabellen-Definitionen zu vergleichen (s. Abb. 10) und stellen fest: Noch nicht identisch - also richtig stellen und dann erst nach Hause gehen.

Mehr zu Informix und Server Studio erfahren Sie in der nächsten Ausgabe der ORDIX News.

Ulrike Kögler info@ordix.de.