20.8 Datenbankabfragen 

Mit einer gelungenen Verbindung lassen sich nun SQL-Kommandos absetzen, und die Datenbank kann gesteuert werden.

20.8.1 Abfragen über das Statement-Objekt 

Für SELECT-Abfragen ist ein Statement-Objekt anzulegen. JDBC bietet dazu die Methode createStatement() an, die eine SQLException auslösen kann. Dies ist eine Methode des Connection-Objekts.

Statement stmt = con.createStatement();

interface java.sql.  Connection  

Statement createStatement() throws SQLException Liefert ein Statement-Objekt, um SQL-Anweisungen zur Datenbank zu schicken.

SQL-Anweisungen ohne Parameter werden normalerweise über das Statement-Objekt ausgeführt. Wird das gleiche SQL-Statement mehrmals ausgeführt, lohnt es sich, ein PreparedStatement zu konstruieren.

SQL-Anweisungen ausführen

Um Informationen auszulesen, benutzen wir die SELECT-Befehle aus SQL und geben sie durch die executeQuery()-Methode der Statement-Schnittstelle an. Der Aufruf liefert uns die Ergebnisse als Zeilen in Form eines ResultSet-Objekts. Wir benutzen executeQuery() für Abfragen und executeUpdate() bei Update-, Insert- oder Delete-Operationen. Wieder dürfen wir das Auffangen von SQLException nicht vergessen.

String query = "SELECT * FROM Tabellenname";
ResultSet rs = stmt.executeQuery( query );

An dieser Stelle sei noch einmal darauf hingewiesen, dass JDBC nicht in die Zeichenketten hineinsieht, die es an den Treiber weiterleitet. Sind die SQL-Anfragen also falsch, lassen sich Fehler schwer finden. So kann zum Beispiel schon die falsche Groß- beziehungsweise Kleinschreibung zu Fehlern in der Datenbank führen. Solche Fehler sind natürlich schwer zu entdecken. Daher bietet es sich an, zum Testen erst die Kommandos auf der Konsole auszugeben. Insbesondere bei zusammengesetzten Ausdrücken finden sich dann schon die Fehler.

interface java.sql.  Statement  

ResultSet executeQuery( String sql ) throws SQLException Führt ein SQL-Statement aus, das ein einzelnes ResultSet-Objekt zurückgibt.

20.8.2 Ergebnisse einer Abfrage in ResultSet 

Das Ergebnis einer Abfrage durch executeQuery() wird in einer Ergebnistabelle vom Typ ResultSet zurückgegeben. Mit Methoden von ResultSet lassen sich die unterschiedlichen Spalten ansprechen und die Zeilen auswerten.

SELECT Pflanzenname, Preis FROM Pflanzen

System.out.println( rSet.getString(1) + "\n" + rSet.getString(2) );

Ist die Abfrage über alle Elemente einer Zeile formuliert, zum Beispiel

SELECT * FROM Pflanzen

so muss erst über Connection.getMetaData() die Struktur der Tabelle ermittelt werden. Erst dann können wir mit den angemessenen Methoden auslesen. Dazu später mehr.

Um das ResultSet auszuwerten, müssen wir zunächst in die erste Zeile springen. Dies geschieht mit der next()-Methode von ResultSet. Danach sind wir mit getXXX() in der Lage, die Spalten dieser Zeile auszuwerten. Um weitere Zeilen zu erhalten, nutzen wir wieder next(). Die Methode gibt false zurück, falls es keine neue Zeile mehr gibt. Die Abfragen befinden sich somit oft in einer while-Schleife.

while ( rSet.next() )
  System.out.print( rSet.getString(1) + "\n" + rSet.getString(2) );

interface java.sql.  ResultSet  

String getString( int column ) throws SQLException Liefert aus der aktuellen Zeile den Inhalt der Spalte column als String. Die erste Spalte ist mit 1 adressiert. Ist in der Tabelle der SQL-Eintrag NULL, so ist das Ergebnis der Methode auch null.

String getString( String columnName ) throws SQLException Liefert in der aktuellen Zeile den Inhalt der Spalte mit dem Namen columnName als String.

boolean next() throws SQLException Der erste Aufruf muss next() sein, damit der Cursor auf die erste Zeile gesetzt wird. Die folgenden Aufrufe setzen den Cursor immer eine Zeile tiefer. Ist der Eingabestrom der vorangehenden Zeile noch geöffnet, wird dieser automatisch geschlossen.

20.8.3 Java und SQL-Datentypen 

Jeder Datentyp in SQL hat einen mehr oder weniger passenden Datentyp in Java. Die Klasse java.sql.Types identifiziert alle SQL-Typen. So konvertiert der JDBC-Treiber bei jeder getXXX()-Methode diese zu einem Datentyp, aber auch nur dann, wenn diese Konvertierung möglich ist. So lässt er es nicht zu, bei einem kommenden String eine getInteger()-Methode auszuführen. Umgekehrt lassen sich alle Datentypen als String auslesen. Die folgende Tabelle zeigt die Übereinstimmungen. Einige SQL-Datentypen können durch mehrere Zugriffsmethoden geholt werden: Ein INTEGER lässt sich mit getInt() oder getBigDecimal() holen und TIMESTAMP mit getDate(), getTime() oder getTimestamp().

In der Regel passen die Typen recht gut in das Java-System. So liefert getInt() ein int und getString() ein String-Objekt. Für einige Daten wurden jedoch spezielle Klassen entworfen; am auffälligsten ist die Klasse java.sql.Date, auf die wir gleich noch zu sprechen kommen.

ResultSet result = stmt.executeQuery( "SELECT Name, GebTag FROM Personen" );
result.next();
String   name1 = result.getString( "Name" );
Date  whatDay1 = result.getDate( "GebTag" );

Die getXXX()-Methoden

Die nun folgenden Funktionen sind die getXXX()-Methoden der Klasse ResultSet. Sie existieren in zwei Ausführungen: Bei der ersten Variante ist eine Ganzzahl als Parameter aufgeführt. Dieser gibt die Spalte der Operation an. Sie beginnt immer bei 1. Die zweite Variante erlaubt es, den Namen der Spalte anzugeben. Alle Methoden können eine SQLException in dem Fall auslösen, dass etwas mit der Datenbank nicht stimmt. Der throws-Ausdruck ist also nicht mehr explizit angegeben. Ist ein Eintrag in der Datenbank mit NULL belegt, so liefert die Methode null zurück.

interface java.sql.  ResultSet  

String getString( int Spalte | String ) Liefert den Wert in der Spalte als Java String.

boolean getBoolean( int | String ) Liefert den Wert in der Spalte als Java boolean.

byte getByte( int | String ) Liefert den Wert in der Spalte als Java byte.

short getShort( int | String ) Liefert den Wert in der Spalte als Java short.

int getInt( int | String ) Liefert den Wert in der Spalte als Java int.

long getLong( int | String ) Liefert den Wert in der Spalte als Java long.

float getFloat( int | String ) Liefert den Wert in der Spalte als Java float.

double getDouble( int | String ) Liefert den Wert in der Spalte als Java double.

BigDecimal getBigDecimal( int | String, int scale) Liefert den Wert in der Spalte als java.lang.BigDecimal-Objekt.

byte[] getBytes( int | String ) Liefert den Wert in der Spalte als Bytefeld. Es besteht aus uninterpretierten Rohdaten.

Date getDate( int | String ) Liefert den Wert in der Spalte als java.sql.Date-Objekt.

Time getTime( int | String ) Liefert den Wert in der Spalte als java.sql.Time-Objekt.

Timestamp getTimestamp( int | String ) Liefert den Wert in der Spalte als java.sql.Timestamp-Objekt.

InputStream getAsciiStream( int | String ) Die Methode gibt über einen InputStream Zugriff auf den Inhalt der Spalte. Nützlich ist dies für den Datentyp LONGVARCHAR. Der JDBC-Treiber konvertiert die Daten mitunter in das ASCII-Format.

InputStream getBinaryStream( int | String ) Die Methode erlaubt es, auf den Inhalt der Spalte als InputStream zuzugreifen. Nützlich ist dies für den Datentyp LONGVARBINARY. Der JDBC-Treiber konvertiert die Daten mitunter in das ASCII-Format. Bevor aus einer anderen Spalte Daten ausgelesen werden, müssen die Daten vom Stream gelesen werden. Ein weiterer Aufruf schließt selbstständig den Datenstrom. Die Methode available() liefert die Rückgabe null, falls keine Daten anliegen.

Die Verwandtschaft von java.sql.Date und java.util.Date

Ein Datenbankprogramm, das die Klasse java.sql.Date nutzt und ebenfalls java.util eingebunden hat, wird bei der Compilierung zu einem Fehler führen, da der Compiler den Bezug auf die Klasse Date nicht zuordnen kann. Denkbar sind zwei Lösungen. Wird util nur deswegen eingebunden, weil Datenstrukturen, aber nicht die Date-Klasse genutzt werden, dann ließe sich die import-Anweisung umbauen, so dass die von util genutzten Klassen direkt in import genannt werden, etwa import java.util.ArrayList. Bei vielen benutzten Klassen aus dem util-Paket ist aber eine andere Lösung einfacher. Wir setzen vor die Klasse, die uns Ärger bereitet, einfach die volle Qualifizierung, schreiben also zum Beispiel:

java.sql.Date date = rs.getDate( "Geburtsdatum" );

Ein weiteres Problem betrifft die Konvertierung der beiden Klassen. Wollen wir beispielsweise eine Zeichenkette aus der Eingabe in eine Datenbank schreiben, dann haben wir das Problem, dass die Konvertierung mittels DateFormat nur ein java.util.Date liefert. Das Einzige, was uns bleibt, ist, von der Klasse Date aus dem util-Paket mittels getTime() die Millisekunden seit dem 1. Januar 1970, 00:00:00 GMT zu holen (natürlich mit der Einschränkung, dass wir zeitlich nicht vor 1970 liegen).

java.sql.Date sqlDate = new java.sql.Date( utilDate.getTime() );

Der Konstruktor von java.sql.Date() mit den Millisekunden ist auch der einzige Konstruktor, der nicht veraltet ist. Daneben hat die Klasse java.sql.Date aber noch drei andere Methoden:

class java.sql.  Date  
extends java.util.Date

static Date valueOf( String s ) Wandelt einen String im JDBC (also yyyy-mm-dd) in ein Date-Objekt um.

String toString() Liefert das Datum im JDBC-Datenformat.

void setTime( long date ) Setzt das Datum mit den Millisekunden.

Date, Time und Timestamp

Datums-Angaben einer Datenbank werden durch Date, Time und Timestamp repräsentiert. java.sql.Date liefert eine Genauigkeit auf Millisekunden wie auch java.util.Date. Time leitet von java.util.Date ab – nicht von java.sql.Date, was intuitiv wäre – und implementiert Formatierungs- und Parsing-Funktionalität. Timestamp (auch eine Unterklasse von java.util.Date) liefert genauere Angaben als java.sql.Date, nämlich noch die Nanosekunden dazu.

20.8.4 Unicode in der Spalte korrekt auslesen 

Der Aufruf von getString() führt bei Unicode-kodierten Zeichenfolgen in der Datenbank unter Umständen zu Problemen. Bemerkbar macht sich dies durch seltsame Zeichen wie ? oder Hexadezimal 0x3f, die an Stelle der Sonderzeichen im String auftauchen. Das liegt oft daran, dass der JDBC-Treiber die Kodierung nicht kennt und einfach jedes ASCII-Byte in ein Char umwandelt, obwohl in der Datenbank Umlaute als 2-Byte Unicode oder Latin-1 kodiert werden.

Bei eigenen Datenbanken funktioniert es, die Kodierung beim Verbindungsaufbau ausdrücklich zu setzen, um damit eine Konvertierung vorzuschreiben. getString() sollte dann die richtige Zeichenkette liefern. Bei anderen Datenbanken funktioniert es wiederum, den Text als Bytefeld zu holen und dann ausdrücklich umzukodieren. Das Folgende ist etwa eine Lösung für PostgreSQL.

new String( read_rs.getBytes(1), "ISO-8859–1" )

20.8.5 wasNull() bei ResultSet 

Ist der Wert einer Spalte Null, dann kann eine Anfrage mit der getXXX()-Methode keinen Wert liefern. Dennoch wird ein Aufruf mit getXXX() eingesetzt, denn die Behandlung von Nullwerten ist in JDBC recht ungewöhnlich gelöst. Wir würden erwarten, dass es eine Funktion isNull(Spalte) auf einem ResultSet-Objekt gibt, die uns ja oder nein liefert hinsichtlich der Frage, ob ein Spalteninhalt unbelegt ist. Dass die Methode wasNull() heißt, ist vielleicht noch zu verkraften, aber dass sie parameterlos ist, erstaunt. Der allgemeine Vorgang bei der Null-Abfrage einer Spalte ist:

rs.getXXX( Spalte )

is ( rs.wasNull() )
  out( "Null" );

20.8.6 Wie viele Zeilen hat ein ResultSet? 

Um herauszufinden, wie viele Zeilen ein ResultSet liefern kann, lassen sich trickreiche JDBC2-Eigenschaften nutzen. Soll in der Variablen row die Anzahl Zeilen stehen, schreiben wir:

rs.last();
int rows = rs.getRow();
rs.beforeFirst();

Bei dieser Programmierung muss natürlich ein Treiber JDBC2-fähig sein und scrollbare Cursor unterstützen, das heißt Cursor, die auch rückwärts laufen können. Gleichzeitig muss dann aber auch beim Statement ein scrollbarer Cursor angemeldet werden. Dazu dient die Zeile:

stmt = con.createStatement( ResultSet.TYPE_SCROLL_INSENSITIVE,
                            ResultSet.CONCUR_UPDATABLE );

Unterstützt ein Treiber kein JDBC2, kann immer noch über eine Zeile wie SELECT COUNT(*) erfragt werden, wie viele Ergebnisse die Datenbank produziert.