Artikel

Juli 2005 | Artikel

PHP ruft DB2

(Link zum Artikel: http://www.it-republik.de/php/artikel/0599)

IBM DB2 Stored Procedures mit PHP in Aktion

Text: von Thomas Wiedmann
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share
Hi DB2, PHP is calling. PHP [1] steht nun für Hypertext Preprocessor und ist eine häufig eingesetzte Skriptsprache im Web. Früher war PHP [2] auch unter Privat Home Page ein Begriff. Inzwischen ist diese Skriptsprache aber längst den Kinderschuhen entwachsen und macht sich auf den Weg, in der großen IT-Welt ein Wörtchen mitzureden. Damit das auch richtig klappen kann, muss PHP natürlich auch mit den dicken Datenbanken reden können.

Bevor wir aber richtig loslegen, liste ich schnell noch die Komponenten auf, mit denen im Laufe des folgenden Artikels gearbeitet wird:

  • Windows 2000
  • Apache 1.3.8
  • DB2/NT 8.1
  • PHP 4.3.2
  • MS-Visual C 6.0
Alles zusammen auf einem Windows-PC installiert, ist die Testsituation für den folgenden Artikel. Grundkenntnisse zu den jeweiligen Komponenten sind notwendig, um die folgenden Beispiele nachvollziehen zu können. Wie und ob PHP auf einer AS/400 arbeitet und zu installieren ist, können Sie übrigens in [3] nachlesen.
ODBC und der DB2/CLI
PHP nutzt die ODBC-Schnittstelle von DB2 und damit das DB2/CLI-Interface. Voraussetzung für alles folgende ist dementsprechend ein funktionierender DB2-Client auf dem PC oder Server, wo auch PHP installiert ist. Die Installation des DB2-Client soll aber nicht Thema dieses Artikels sein. Wir setzen voraus, dass alles notwendige vorhanden ist, also auch der Zugriff auf die DB2 Beispieldatenbank SAMPLE. Im Zweifelsfalle wenden Sie sich bitte an den bereits häufiger zitierten DBA Ihres Vertrauens, der Ihnen sicher gerne weiter hilft.
First Contact oder Hello World
Um eine Datenbankverbindung aufzubauen, benötigen wir die ODBC-Extension von PHP. Diese muss in der PHP.INI nicht extra installiert werden, sondern ist schon per Default aktiviert.
  1. hello_world.php:
  3. <?php
  5. $hDB = odbc_connect('SAMPLE','xx','yy');
  6. if (empty($hDB)) {
  7. echo "Verbindungsaufbau misslungen..";
  8. die();
  9. } else {
  10. echo "Verbindungsaufbau ok!";
  11. odbc_close($hDB);
  12. }
  14. ?>
Das Skript hello_world.php versucht, eine Verbindung via odbc_connect() zur DB2-Beispieldatenbank SAMPLE aufzubauen. Ist der zurückgegebene Handle $hDB leer, dann ist etwas schiefgegangen. Je nach Einstellung in der php.ini sehen Sie dann den Fehler direkt im Browser oder nur in dem Logfile error.log von Apache, welches im Unterverzeichnis logs zu finden ist. Ist der User XX gültig und das Password YY korrekt, sollten sie folgende Meldung in Ihrem Browser sehen (Abb. 1).
Bis hierher sollte es keine Probleme gegeben haben und wirklich neues habe ich Ihnen auch noch nicht verraten. Im nächsten Schritt lesen wir die Versionsnummern von DB2 aus. Ein Blick in den Systemkatalog bringt eine kleine Tabelle namens SYSIBM.SYSVERSIONS zu tage, deren Inhalt die gesuchte Information liefert. Mit dem kleinen Programm in Listing 1 lassen wir uns das Ganze anzeigen.

Listing 1
  1. GetDB2Version.php: (Ausschnitt)
  4. [..]
  5. /**
  6. * SQL-Abfrage aufbauen und ausführen
  7. */
  8. echo "<HTML>\n";
  9. echo "<HEAD></HEAD>\n";
  10. echo "<BODY>\n";
  11. echo "<TABLE border='1' >\n";
  13. $sQuery = "SELECT * FROM sysibm.sysversions
  14. FOR READ ONLY";
  16. // Query ausführen
  17. $hResult = odbc_exec($hDB,$sQuery);
  18. if ($hResult) {
  19. // anzahl Spalten ermitteln
  20. $nCol = odbc_num_fields($hResult);
  22. // Tabellen Header aufbauen
  23. echo "<TR>\n";
  24. for ($i=1;$i<=$nCol;$i++) {
  25. $sFieldName = odbc_field_name($hResult,$i);
  26. echo "<TH>".$sFieldName."</TD>";
  28. }
  29. echo "</TR>\n";
  31. // Alle Datenzeilen einlesen
  32. while (odbc_fetch_row($hResult)) {
  34. // Tabellen Datenzeile aufbauen
  35. echo "<TR>\n";
  36. for ($i=1;$i<=$nCol;$i++) {
  37. $sFieldValue = odbc_result($hResult,$i);
  38. echo "<TD>".$sFieldValue."</TD>";
  40. }
  41. echo "</TR>\n";
  42. }
  43. [..]
Nachdem eine Datenbankverbindung analog dem Beispiel hello_world.php aufgebaut ist, weisen wir der Variablen $sQuery unsere SQL-Abfrage zu. DB2 soll alle Spalten der internen Versionstable liefern und außerdem möchten wir das Ergebnis lesen. Der Zusatz FOR READ ONLY bewirkt, dass DB2 die Daten lesend zur Verfügung stellt. Ohne FOR READ ONLY verweigert DB2 die Aussage mit dem Hinweis SQL0607N "UPDATE" ist für Systemobjekte nicht definiert. Die Tabelle SYSIBM.SYSVERSIONS ist - wie das vorgestellte SYS ja schon sagt - eine Systemtable bzw. ein Systemobjekt, auf das nur lesend zugegriffen werden kann. Ohne den Vermerk FOR READ ONLY versucht PHP offensichtlich, eine Satzsperre (je nach eingestelltem Isolationlevel im DB2/CLI) einzurichten. Mit dem Zusatz FOR READ ONLY funktioniert die Abfrage, und wir erhalten das gewünschte Ergebnis (Abb. 2). Das komplette Listing GetDB2Version.php liegt natürlich wie immer vollständig auf der Heft-CD bereit.
DB2CLI.INI anpassen
Alternativ zur obigen Variante FOR READ ONLY, lässt sich das geschilderte Problem auch mit einer globalen Einstellung in der DB2CLI.INI beheben. Bei der Installation muss dazu die Unterstützung (Optimierung) für Microsoft Visual Basic aktiviert werden. Dabei werden einige Parameter in der DB2CLI.INI gesetzt (Abb. 3). Der wesentliche Parameter ist PATCH2=6, der den Moveable Cursor deaktiviert.
  1. DB2CLI.INI (..Ausschnitt..):
  3. [SAMPLE]
  4. UID=tw
  5. PATCH2=6
  6. PATCH1=1024
  7. LOBMAXCOLUMNSIZE=1048575
  8. LONGDATACOMPAT=1
Alternativ zur Kommandozeile gibt es auch eine GUI-Oberfläche, um die DB2CLI.INI zu bearbeiten.
Abb. 3 zeigt die GUI-Oberfläche, um die ODBC-Verbindung einzustellen. Der wesentliche Eintrag in der DB2CLI.INI ist PATCH2 mit dem Wert 6. Ist dieser Parameter aktiv, kommt es nicht zum oben genannten Problem SQL0607N "UPDATE" ist für Systemobjekte nicht definiert.
Cursortyp SQL_CUR_USE_ODBC
Die dritte und vielleicht eleganteste Variante ist der Einsatz der Option SQL_CUR_USE_ODBC beim Aufbauen der Datenbankverbindung.
  1. /**
  2. * Definition des ODBC Cursortyp
  3. */
  4. $hDB = odbc_connect('SAMPLE','xx','yy',
  5. SQL_CUR_USE_ODBC);
Anstatt den DB2-Client anzupassen, liefert PHP ebenfalls eine Möglichkeit, das oben genannte Problem mit Bordmitteln zu beheben. Der Vorteil hier ist auf jeden Fall: wir als PHP-Programmierer kommen ohne fremde Hilfe ans Ziel. PHP verfügt über insgesamt vier verschiedene Cursortypen für odbc_connect(). Bei vielen speziellen Problemen kann mit diesen Parametern für Abhilfe gesorgt werden. Im PHP-Manual und -Handbuch werden folgende Cursortypen näher beschrieben:
  • SQL_CUR_USE_IF_NEEDED
  • SQL_CUR_USE_ODBC
  • SQL_CUR_USE_DRIVER
  • SQL_CUR_DEFAULT
Im Zweifelsfalle lohnt sich ein Blick auf die PHP-Homepage [1] und die dortigen Newsgroups.
Stored Procedure - warum ?
Stored Procedures (SP) sind kleine Programme, die in C oder Java geschrieben sind und komplett innerhalb der Datenbank abgelegt (gebunden) sind. SP sind klein und schnell in der Ausführung, da das Prepare - also das Prüfen des SQL-Befehles - nur einmal (während der CREATE PROCEDURE) erfolgt. SPs ermöglichen es, ganze Teile der Geschäftslogik in der Datenbank abzulegen. Knifflige Routinen müssen nur einmal geschrieben werden und andere Programme können einfach mit einem CALL gehaltserhoehung_in_prozent (25) darauf zugreifen. Die Themen COM/DCOM und der aktuelle Hype mit den Web Services lässt grüßen. Auch dort wird versucht, komplexe Abläufe hinter allgemein zugänglichen Schnittstellen (APIs) zu verstecken.
Stored Procedure Language SQL
Seit der DB2 Version 7.1 hat IBM auch ein Herz für diejenigen Datenbankentwickler, die zwar perfekt in SQL, aber deren Kenntnisse in C oder JAVA eher ausbaufähig sind. IBM hat als weitere SP-Sprache SQL eingeführt und nennt das ganze nun SQL PL (SQL Procedural Language). Dieses Entgegenkommen wäre sicherlich nicht ohne den kollegialen Druck von Oracle (PL/SQL) und Microsoft (T-SQL) möglich gewesen. Wie dem auch sei, seit der Version 7 kennt DB2 nun SQL als SP-Sprache, und damit sind wir auch beim zentralen Thema angelangt [4].
  1. LOGINLOG.DDL:
  3. CREATE TABLE tw.loginlog (
  4. username CHAR(32) NOT NULL,
  5. message VARCHAR(256),
  6. createtime timestamp NOT NULL
  7. )
Für unser erstes Beispiel legen wir uns schnell die kleine Tabelle LOGINLOG an. Darin sollen alle Anmeldungen und ein optionaler Nachrichtentext gespeichert werden. Nachdem die Tabelle existiert, könnte es eigentlich mit der SP klappen, wenn da nicht EDV im Spiel wäre ...
CREATE PROCEDURE - Hürden
Vor dem (Programm-)Vergnügen steht meist die Installation, so auch hier, aber zuerst schauen wir uns unsere erste SP mit dem Namen LOGINLOG_SP genauer an.
  1. LOGINLOG_SP.DDL:
  3. CREATE PROCEDURE loginlog_sp (IN p_sMsg CHAR(32))
  4. SPECIFIC loginlog_sp
  5. LANGUAGE SQL
  6. BEGIN
  7. INSERT INTO tw.loginlog
  8. (username, message, createtime)
  9. VALUES
  10. (USER, p_sMsg, CURRENT TIMESTAMP);
  11. END!
Auffällig ist der IN-Parameter p_sMsg. Das Kürzel IN bedeutet hier: Es kann ein Wert der SP zur weiteren Bearbeitung übergeben werden. Der Parameter soll vom Typ CHAR und maximal 32 Byte lang sein. Wo es IN gibt, ist auch OUT nicht weit. Mit OUT werden Parameter beschrieben, deren Werte von der SP zurück an das aufrufende Programm gegeben werden. Aber dazu später mehr. Weiterhin gibt es da die Eigenschaft SPECIFIC. Damit wird der echte eindeutige Name der SP festgelegt, in unserem Fall ist er identisch zu dem in der CREATE PROCEDURE-Zeile, also LOGINLOG_SP. Nun kommt LANGUAGE SQL. Dieses Kommando ist optional. Fehlt es, ergänzt DB2 automatisch zu LANGUAGE SQL. Zu guter Letzt der Body mit BEGIN und END. Weitere Details zu SQL PL und deren Syntax [4] würden hier den Rahmen sprengen. Wichtig ist noch der Hinweis auf ein individuelles Befehlsendezeichen - beispielsweise ! - welches im DB2 Command Center eingestellt werden muss. Gut, doch nun schauen wir uns die Fehlermeldungen an, die DB2 beim CREATE PROCEDURE anmerkt.
  1. SQL7032N Die SQL-Prozedur "LOGINLOG_SP" wurde nicht erstellt.
  2. Die Diagnosedatei ist "P0124965.log".
  4. [...]
Wenn wir jetzt die genannte Diagnosedatei P0124965.log im Verzeichnis G:\SQLLIB\function\routine\sqlproc\SAMPLE\TW\tmp suchen, wird uns schnell klar, dass während dem CREATE PROCEDURE ein C-Compiler aufgerufen wird, um die notwendigen Dateien für das SP zu erzeugen. Unsere schöne SQL-Procedure wird intern automatisch in C-Code umgewandelt und an die Datenbank gebunden. Damit DB2 aber den Compiler richtig nutzen kann, muss die DB2-Umgebungsvariable DB2_SQLROUTINE_COMPILER_PATH korrekt gesetzt sein.
DB2_SQLROUTINE_COMPILER_PATH
DB2-Umgebungsvariablen werden am besten mit dem Programm DB2SET.EXE auf Kommandoebene (MS-DOS-Eingabeaufforderung) gesetzt (Abb. 4). Eine DB2-Umgebungsvariable hat nichts mit den sonstigen Windowsvariablen der Art Environment zu tun, sondern wird extra in der Registry verwaltet.
Der Umgebungsvariablen DB2_SQLROUTINE_COMPILER_PATH wird der Pfad zur Datei vcvars32.bat zugewiesen. In diesem Batchjob werden die notwendigen Compilervariablen für den Microsoft C/C++ Compiler gesetzt. Nun gibt es noch zwei kleine Hürden beim Setzen dieser Variablen. Erstens darf kein Leerzeichen links oder rechts vom Gleichheitszeichen sein und zweitens muss der Pfadname in doppelten Anführungszeichen stehen, da er Leerzeichen enthält.
Jetzt aber...
Wenn wir nun versuchen unsere SQL-Procedure LOGINLOG_SP zu erzeugen, meldet sich DB2 - nach einigem Gerumpel auf der Platte - netterweise mit DB20000I Der Befehl SQL wurde erfolgreich ausgeführt. Das bedeutet, wir können unsere SP jetzt ausprobieren. Damit andere Benutzer das neue Paket auch nutzen können, müssen noch die EXECUTE-Rechte auf dem Paket vergeben werden. Bleibt noch das Problem, auf welchen Namen das neue Paket denn eigentlich hört. Denn einfach nur
  1. GRANT EXECUTE ON PACKAGE tw.loginlog_sp TO PUBLIC
klappt nicht, da DB2 den Paketnamen LOGINLOG_SP nicht kennt. Ein Blick in das Verzeichnis, in dem DB2 die erzeugten Pakete ablegt, bringt endlich mehr Klarheit.
Abpictureung 5 zeigt, wo und unter welchem internen Namen DB2 die fertigen Pakete (Stored Procedures) speichert. Hinter der Nummer P3022352 verbirgt sich unsere Procedure LOGINLOG_SP. Die Rechtevergabe muss auf diesem Paketnamen sowie die SP LOGINLOG_SP erfolgen, die das Paket nutzt.
  1. GRANT EXECUTE ON PACKAGE TW.P3022352 TO PUBLIC
  2. GRANT EXECUTE ON PROCEDURE TW.LOGINLOG_SP(CHAR()) TO PUBLIC
Geschafft! Nun können wir unsere SP erst einmal im DB2 Command Center ausprobieren.
  1. DB2 COMMAND CENTER:
  3. CALL tw.loginlog_sp('Es klappt...')
  5. -> Rückgabestatus = 0
Anschließend schauen wir nach, ob sich in der Tabelle der gewünschte Eintrag befindet.
  1. DB2 COMMAND CENTER:
  3. SELECT * FROM tw.loginlog
  5. USERNAME MESSAGE CREATETIME
  6. -------- ------------- ---------------------
  7. TW Es klappt... 2004-03-20-13.03.16.987000
  8. 1 Satz/Sätze ausgewählt.
Damit ist das erste Level geschafft. Die SP existiert und kann angesprochen werden. Im nächsten Schritt versuchen wir das mit PHP nachzubauen.
  1. CallDB2SP.php: (Ausschnitt)
  3. /***
  4. * DB2 Stored Procedure aufrufen
  5. */
  6. $sQuery = "CALL tw.loginlog_sp('PHP kann es auch...')";
  8. // Befehl ausführen
  9. odbc_exec($hDB,$sQuery);
  10. odbc_commit($hDB);
  11. [...]
Der wesentliche Teil im Skript CallDB2SP.php ist hier zu sehen. Analog einer normalen Abfrage wird ein CALL-Befehl für den Aufruf der SP eingesetzt. Als Parameter wird der Text PHP kann es auch übergeben. Anschließend wird der aktuelle Inhalt der Tabelle tw.loginlog als HTML-Tabelle ausgegeben (Abb. 6).
Das PHP-Skript nutzt als Username DBU (Database User). Den User DBU habe ich für meine PHP-Web-Anwendungen eingerichtet und ihm aus Sicherheitsgründen nur die notwendigen Zugriffsrechte gegeben. Und zwar EXECUTE auf tw.loginlog_sp sowie SELECT plus INSERT auf die Tabelle tw.loginlog. Je nach Konzept benötigt man hier natürlich eine sichere Loginroutine, mit der sich der Nutzer zweifelsfrei identifizieren muss. Nun gut, bisher haben wir gesehen, dass PHP erfolgreich Werte an eine DB2-Stored Procedure übergeben kann. Aber wie sieht es eigentlich mit Rückgabewerten aus?
One way street ?
In den Newsgroups kann man immer wieder mal die Frage lesen, wie man denn an die Rückgabewerte einer Stored Procedure käme? Lösungen findet man eher selten, deshalb probieren wir es einfach selber aus:
  1. LOGINLOG_COUNT_SP.DDL:
  3. CREATE PROCEDURE loginlog_count_sp
  4. (OUT p_nCount INT)
  5. SPECIFIC loginlog_count_sp
  6. LANGUAGE SQL
  7. BEGIN
  8. SELECT COUNT (*) INTO p_nCount
  9. FROM tw.loginlog;
  11. END!
Unsere neue Procedure loginlog_count_sp soll die Anzahl der Datensätze in der Tabelle loginlog zählen und das Ergebnis in Form eines Integer-Wertes zurück geben. An sich ist dies kein großes Problem und in der SQL-Console bzw. auf Kommandoebene klappt es auch widerspruchslos.
  1. CALL tw.loginlog_count_sp(?)
  3. Wert der Ausgabeparameter
  4. -------------------------
  5. Parametername: P_NCOUNTParameterwert: 2
  6. Rückgabestatus = 0
Nun gut, dann bauen wir das mal schnell mit PHP nach. Dieser Meinung war ich zuerst auch und mein erster Versuch sah dann wie in Listing 2 aus.

Listing 2
  1. CallDB2CountSP.php: (Ausschnitt)
  2. [...]
  3. /***
  4. * DB2 Stored Procedure aufrufen
  5. */
  6. $sQuery = "CALL tw.loginlog_count_sp('?')";
  8. // Prepare/Execute wegen HOST Variablen (?)
  9. $stmt = odbc_prepare($hDB,$sQuery);
  10. if ($stmt) {
  12. $nCount = 0;
  13. $aParam = array();
  14. $aParam['count'] = 0;
  15. if (odbc_execute($stmt,$aParam)) { // Line 33
  17. // Alle Datenzeilen einlesen
  18. while (odbc_fetch_row($stmt)) {
  19. [...]
  21. Warning: SQL error: [IBM][CLI Driver][DB2/NT] SQL0469N Der Parametermodus (IN, OUT oder INOUT) ist für einen Parameter in der Prozedur "LOGINLOG_COUNT_SP" mit dem spezifischen Namen "LOGINLOG_COUNT_SP" (Parameternummer "0", Name "P_NCOUNT") ungültig. SQLSTATE=42886 , SQL state 42886 in SQLExecute in ..\calldb2countsp.php on line 33
Doch leider funktioniert es nicht, und ich habe keinen besseren Ansatz gefunden. Die hier gezeigte Technik mit odbc_prepare() und odbc_execute() arbeitet zwar mit normalen DML-Befehlen wie SELECT, INSERT, UPDATE oder DELETE, aber offensichtlich nicht im Zusammenspiel mit Stored Procedures. Auch der passende Hinweis auf den Developer-Seiten von IBM [5] liefert wenig Tröstliches.

Offizielle IBM-Information zum Problem mit PHP und Output-Parametern [5]
Problem Cannot call stored procedures with output parameters via PHP and ODBC because DB2 does not currently have a PHP driver. The PHP libraries are not supported. Cause Because DB2 does not have a PHP driver, the PHP libraries are not supported. Solution One possible workaround is to change the way the stored procedure returns data to allow PHP to retrieve the information.
Flinte ins Korn werfen?
Was tun? Warten bis IBM ihren DB2/ODBC-Treiber verbessert oder sich einen Workaround überlegen. Zweites entspricht doch eher unserem PHP-Magazin-Image. Denn SQL PL bietet eine RESULT SETS-Eigenschaft, die wir uns zu Nutzen machen können [6].
  1. GETRESULTSET_SP.DDL:
  3. CREATE PROCEDURE GetResultSet()
  4. SPECIFIC GetResultSet
  5. RESULT SETS 1
  6. LANGUAGE SQL
  8. BEGIN
  10. -- definiere cursor mit Return
  11. DECLARE c1 CURSOR WITH RETURN FOR
  12. SELECT count (*) as Anzahl FROM tw.loginlog;
  14. -- stellt ein Result-Set zur Verfügung
  15. OPEN c1;
  17. END!
Neu in dieser SP ist die Eigenschaft RESULT SETS 1. Damit wird definiert: Diese Procedure soll einen (!) Resultset-Cursor zurück geben. Die spezielle Benennung SETS 1 lässt vermuten, dass hier mehrere Ergebnismengen gleichzeitig zurück gegeben werden können. Und richtig, ein Blick in [4] zeigt, wie dies geht. Zur Zeit genügt uns aber ein Resultset. CURSOR WITH RETURN bestimmt den Cursor, der ausgeführt werden soll. In unserem Fall handelt es sich um statisches SQL, da keine variablen Teile wie Parameter oder HOST-Variablen im Einsatz sind. Mit OPEN C1 wird schlussendlich der eigentliche Cursor C1 für die Clientapplikation (unser PHP-Programm !) geöffnet. Nachdem wir diese Procedure erzeugt haben, dürfen wir nicht vergessen, wieder die notwendigen EXECUTE-Rechte für den Web-User DBU auf dieses Paket zu erteilen. Und immer wenn es funktioniert, sieht das Ergebnis genial einfach aus (Abb. 7).
Was haben wir erreicht? Abpictureung 7 zeigt Daten an, die von einer DB2-SP erzeugt worden sind, zwar nicht direkt über die OUT-Parameter, aber dafür mittels dem übergebenen Resultset. Eventuell ist diese Lösung sogar flexibler als der Einsatz von OUT-Parametern.
  1. GetResultSet.php: (Ausschnitt)
  3. [...]
  4. /***
  5. * DB2 Stored Procedure aufrufen
  6. */
  7. $sQuery = "CALL tw.GetResultSet()";
  9. // CALL ausführen
  10. $hResult = odbc_exec($hDB,$sQuery);
  11. if ($hResult) {
  12. // anzahl Spalten ermitteln
  13. $nCol = odbc_num_fields($hResult);
  15. [...]
Aus Sicht des PHP-Skriptes GetResultSet.php verhält sich die SP-Abfrage wie eine normale SQL-Abfrage. Der gesamte Ablauf sieht letztlich genau so aus, wie das eingangs gezeigte Skript GetDB2Version.php. Die Möglichkeit, einen Cursor aus der SQL-Procedure zurück an das aufrufende Clientprogramm zu übergeben, hat auch für PHP die DB2-Tür ganz weit aufgestoßen.
Quintessenz
Die hier gezeigten SQL PL-Beispiele sind zwar recht einfach gehalten, zeigen aber doch einen gangbaren Weg auf, damit PHP auch in dieser Liga mitspielen kann. Die Parameterübergabe ist möglich. Zudem haben wir die Tür genügend weit aufgestoßen, um die dahinter liegenden Möglichkeiten mit dem DB2-Feature SQL PL zu erkennen und schätzen zu lernen. Ab der kommenden DB2 Version 9 wird die etwas hakelige Geschichte mit dem C-Compiler abgelöst werden, dann soll direkt ein entsprechender Bytecode erzeugt werden. Lassen wir uns einfach überraschen.
Thomas Wiedmann ist Anwendungs- und Datenbankentwickler für individuelle Softwarelösungen, Autor des Buches DB2 sowie IBM Certified DB2 Administrator. Wenn er nicht gerade Musik hört, liest oder fotografiert, beschäftigt er sich mit Datenbanken und Web-Applikationen. Sie können seine Webseite unter http://www.twiedmann.de einsehen.
Literatur und Links

Kommentare

+ Neuen Kommentar verfassen