20.8 Datenbankabfragen
 
Mit einer gelungenen Verbindung lassen sich SQL-Kommandos absetzen, und die Datenbank kann gesteuert werden.
20.8.1 Abfragen über das Statement-Objekt
 
Für alle SQL-Anfragen und Manipulationen der Datenbank ist zuerst ein Statement-Objekt von der Connection zu erfragen. JDBC bietet dazu die Methode createStatement() an, die eine SQLException auslösen kann.
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 ausführen
Das Statement-Objekt nimmt mit executeQuery() eine Zeichenfolge mit einer SQL-SELECT Anweisung entgegen und mit executeUpdate() eine Anweisung für eine Update-, Insert- oder Delete-Operation. In beiden Fällen dürfen wir das Auffangen von SQLException nicht vergessen.
String query = "SELECT * FROM GEODB_TYP";
ResultSet rs = stmt.executeQuery( query );
Der Aufruf liefert uns die Ergebnisse als Zeilen in Form eines ResultSet-Objekts.
Hinweis Der JDBC-Treiber überprüft die SQL-Anweisungen nicht, sondern leitet sie fast ungesehen an die Datenbank weiter. Sind die SQL-Anfragen falsch, lassen sich Fehler schwer 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. |
Wird die gleiche SQL-Anweisung mehrmals ausgeführt, lohnt es sich, ein Prepared-Statement zu konstruieren.
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 können Sie die unterschiedlichen Spalten ansprechen und die Zeilen auswerten.
ResultSet rs = stmt.executeQuery( "SELECT * FROM GEODB_TYP" );
Da die Spalten verschiedene Datentypen besitzen können, bietet die Schnittstelle ResultSet für jeden Datentyp eine entsprechende Methode getXXX() an – XXX ist der Datentyp. Da alle Spalten immer als String ausgelesen werden können, ist es möglich, einfach getString() zu verwenden.
Beispiel Mit der getString()-Funktion lesen wir eine bestimmte Ergebnisspalte aus.
System.out.println( rs.getString(2) );
Der numerische Parameter steht für den Spaltenindex, der bei 1 beginnt. Wird der Methode getXXX() ein String übergeben, so bestimmt er den Namen der Spalte.
|
Um mit der Auswertung vom ResultSet beginnen zu können, muss der Treiber die Informationen von der Datenbank bezogen haben. Ein Aufruf der next()-Methode von ResultSet setzt den internen Cursor auf die erste Zeile der geladenen Ergebnisse. Danach geben diverse getXXX()-Methoden die Spalten der Zeile frei. Um weitere Zeilen zu erhalten, nutzen wir wieder next(). Die Methode gibt false zurück, falls es keine neue Zeile mehr gibt; eine while-Schleife ist für die Abfragen genau richtig:
while ( rs.next() )
System.out.printf( "%s, %s, %s%n", rs.getString(1),
rs.getString(2), rs.getString(3) );
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. Falls es keine Zeilen mehr gibt, liefert die Methode false. |
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, doch 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().
Tabelle 20.4
Datentypen in SQL und ihre Entsprechung in Java
Java-Methode
|
SQL-Typ
|
getInt()
|
INTEGER
|
getLong()
|
BIG INT
|
getFloat()
|
REAL
|
getDouble()
|
FLOAT
|
getBignum()
|
DECIMAL
|
getBigDecimal()
|
NUMBER
|
getBoolean()
|
BIT
|
getString()
|
VARCHAR
|
getString()
|
CHAR
|
getAsciiStream()
|
LONGVARCHAR
|
getDate()
|
DATE
|
getTime()
|
TIME
|
getTimestamp()
|
TIME STAMP
|
getObject()
|
jeder Typ
|
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.
Beispiel Befinden sich in einem ResultSet Namen als Zeichenketten und Geburtsdaten als Datum, dann liefern getString() und getDate() diese Informationen.
ResultSet rs = stmt.executeQuery( "SELECT Name, GebTag FROM Personen" );
rs.next();
String name1 = rs.getString( "Name" );
Date whatDay1 = rs.getDate( "GebTag" );
|
Die getXXX()-Methoden
Die nun folgenden Funktionen sind die getXXX()-Methoden der Klasse ResultSet. Zwei Ausführungen sind verfügbar: 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 ermöglicht ü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, sofern 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, sodass 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 im String an Stelle der Sonderzeichen 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, kann eine Anfrage mit der getXXX()-Methode keinen Wert liefern. Dennoch wird ein Aufruf mit getXXX() eingesetzt, da die Behandlung von Nullwerten in JDBC recht ungewöhnlich gelöst ist. 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.
|