Java SE 8 Standard-Bibliothek  
Professionelle Bücher. Auch für Einsteiger.
 
Inhaltsverzeichnis


Vorwort
1 Neues in Java 8 und Java 7
2 Fortgeschrittene String-Verarbeitung
3 Threads und nebenläufige Programmierung
4 Datenstrukturen und Algorithmen
5 Raum und Zeit
6 Dateien, Verzeichnisse und Dateizugriffe
7 Datenströme
8 Die eXtensible Markup Language (XML)
9 Dateiformate
10 Grafische Oberflächen mit Swing
11 Grafikprogrammierung
12 JavaFX
13 Netzwerkprogrammierung
14 Verteilte Programmierung mit RMI
15 RESTful und SOAP-Web-Services
16 Technologien für die Infrastruktur
17 Typen, Reflection und Annotationen
18 Dynamische Übersetzung und Skriptsprachen
19 Logging und Monitoring
20 Sicherheitskonzepte
21 Datenbankmanagement mit JDBC
22 Java Native Interface (JNI)
23 Dienstprogramme für die Java-Umgebung
Stichwortverzeichnis

Jetzt Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Java SE 8 Standard-Bibliothek von Christian Ullenboom
Das Handbuch für Java-Entwickler
Buch: Java SE 8 Standard-Bibliothek

Java SE 8 Standard-Bibliothek
Pfeil 21 Datenbankmanagement mit JDBC
Pfeil 21.1 Relationale Datenbanken
Pfeil 21.1.1 Das relationale Modell
Pfeil 21.2 Datenbanken und Tools
Pfeil 21.2.1 HSQLDB
Pfeil 21.2.2 Weitere Datenbanken *
Pfeil 21.2.3 Eclipse Data Tools Platform (DTP) zum Durchschauen von Datenbanken
Pfeil 21.3 JDBC und Datenbanktreiber
Pfeil 21.3.1 Treibertypen *
Pfeil 21.3.2 JDBC-Versionen *
Pfeil 21.4 Eine Beispielabfrage
Pfeil 21.4.1 Schritte zur Datenbankabfrage
Pfeil 21.4.2 Ein Client für die HSQLDB-Datenbank
Pfeil 21.5 Mit Java an eine Datenbank andocken
Pfeil 21.5.1 Der Treiber-Manager *
Pfeil 21.5.2 Den Treiber laden
Pfeil 21.5.3 Eine Aufzählung aller Treiber *
Pfeil 21.5.4 Log-Informationen *
Pfeil 21.5.5 Verbindung zur Datenbank auf- und abbauen
Pfeil 21.6 Datenbankabfragen
Pfeil 21.6.1 Abfragen über das Statement-Objekt
Pfeil 21.6.2 Ergebnisse einer Abfrage in ResultSet
Pfeil 21.6.3 Java und SQL-Datentypen
Pfeil 21.6.4 Date, Time und Timestamp
Pfeil 21.6.5 Unicode in der Spalte korrekt auslesen
Pfeil 21.6.6 Eine SQL-NULL und wasNull() bei ResultSet
Pfeil 21.6.7 Wie viele Zeilen hat ein ResultSet? *
Pfeil 21.7 Elemente einer Datenbank ändern
Pfeil 21.7.1 Einzelne INSERT-, UPDATE- oder DELETE-Anweisungen senden
Pfeil 21.7.2 Aktualisierbares ResultSet
Pfeil 21.7.3 Batch-Updates
Pfeil 21.8 Die Ausnahmen bei JDBC, SQLException und Unterklassen
Pfeil 21.8.1 JDBC-Fehlerbasisklasse SQLException
Pfeil 21.8.2 SQLWarning
Pfeil 21.9 ResultSet und RowSet *
Pfeil 21.9.1 Die Schnittstelle RowSet
Pfeil 21.9.2 Implementierungen von RowSet
Pfeil 21.9.3 Der Typ CachedRowSet
Pfeil 21.9.4 Der Typ WebRowSet
Pfeil 21.10 Vorbereitete Anweisungen (Prepared Statements)
Pfeil 21.10.1 PreparedStatement-Objekte vorbereiten
Pfeil 21.10.2 Werte für die Platzhalter eines PreparedStatement
Pfeil 21.11 Transaktionen
Pfeil 21.13 Vorbereitete Datenbankverbindungen
Pfeil 21.13.1 DataSource
Pfeil 21.13.2 Gepoolte Datenbankverbindungen
Pfeil 21.14 Zum Weiterlesen
 
Zum Seitenanfang

21.6Datenbankabfragen Zur vorigen ÜberschriftZur nächsten Überschrift

Mit einer gelungenen Verbindung und dem Connection-Objekt in der Hand lassen sich SQL-Kommandos absetzen, und die Datenbank kann gesteuert werden.

 
Zum Seitenanfang

21.6.1Abfragen über das Statement-Objekt Zur vorigen ÜberschriftZur nächsten Überschrift

Für alle SQL-Abfragen und Manipulationen der Datenbank sind Anweisungsobjekte von der Connection zu erfragen. JDBC bietet drei Typen von Anweisungsobjekten:

  • normale Anweisungen vom Typ Statement

  • vorbereitete Anweisungen (Prepared Statement) vom Typ PreparedStatement

  • gespeicherte Prozeduren (Stored Procedures) vom Typ CallableStatement

Für einfache Anweisungen liefert uns die Methode createStatement() ein Statement-Objekt, mit dem sich im nächsten Schritt Abfragen stellen lassen.

Klassendiagramm für Connection

Abbildung 21.5Klassendiagramm für Connection

[zB]Beispiel

Hole ein Statement-Objekt für einfache Abfragen:

Statement stmt = con.createStatement();

Die Methode kann – wie fast alle Methoden aus dem SQL-Paket – eine SQLException auslösen.

interface java.sql.Connection
extends Wrapper, AutoCloseable
  • Statement createStatement() throws SQLException
    Liefert ein Statement-Objekt, um SQL-Anweisungen zur Datenbank zu schicken.

SQL-Anweisungen ausführen

Das Statement-Objekt nimmt mit der Methode executeQuery(String) eine Zeichenfolge mit einer SQL-SELECT-Anweisung entgegen und mit executeUpdate(String) eine Anweisung für eine UPDATE-, INSERT- oder DELETE-Operation.

[zB]Beispiel

Erfrage alle Spalten der Tabelle »Customer«:

String query = "SELECT * FROM Customer";
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-Abfragen 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 so leichter Fehler.

interface java.sql.Statement
extends Wrapper, AutoCloseable
  • ResultSet executeQuery(String sql) throws SQLException
    Führt ein SQL-Statement aus, das für die Ergebnisliste ein einzelnes ResultSet-Objekt zurückgibt.

Wird die gleiche SQL-Anweisung mehrmals ausgeführt, lohnt es sich, ein PreparedStatement zu konstruieren.

 
Zum Seitenanfang

21.6.2Ergebnisse einer Abfrage in ResultSet Zur vorigen ÜberschriftZur nächsten Überschrift

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. Mit diversen Methoden von ResultSet können wir die unterschiedlichen Spalten ansprechen und die Zeilen auswerten. Um weitere Zeilen zu erhalten, nutzen wir wieder next(). Die Methode gibt false zurück, falls es keine neue Zeile mehr gibt.

[zB]Beispiel

Gehe mit einer while-Schleife durch die gesamte Ergebnisliste, und gib das Ergebnis der Spalten 1, 2 und 3 auf dem Bildschirm aus:

ResultSet rs = stmt.executeQuery( "SELECT * FROM Customer" );
while ( rs.next() )
System.out.printf( "%s, %s, %s%n", rs.getString(1),
rs.getString(2), rs.getString(3) );

Der numerische Parameter steht für den Spaltenindex, der bei 1 beginnt. Wird der Methode getString(…) ein String übergeben, so bestimmt er den Namen der Spalte.

Die Methode executeQuery(String) liefert immer ein ResultSet-Objekt (bis auf den Fehlerfall, der zu einer SQLException führt), auch wenn das ResultSet keine Zeilen enthält. So lassen sich über das ResultSet immer noch Metadaten abfragen.

interface java.sql.ResultSet
extends Wrapper, AutoCloseable
  • 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.

getXXX(int) und getXXX(String)

Da die Spalten verschiedene Datentypen besitzen können, bietet die Schnittstelle ResultSet für jeden Datentyp eine entsprechende Methode getXXX(…) an – XXX ist ein Datentyp wie int. Zwei Ausführungen der Methode getXXX(…) sind verfügbar: Bei der ersten Variante ist eine Ganzzahl als Parameter aufgeführt. Dieser Parameter gibt die Spalte der Operation an. Die zweite Variante erlaubt es, den Namen der Spalte anzugeben.

Da alle Spalten immer als String ausgelesen werden können, ist es möglich, einfach getString(…) zu verwenden. Im Folgenden soll der Typ String stellvertretend für andere Typen wie int, double usw. stehen.

interface java.sql.ResultSet
extends Wrapper, AutoCloseable
  • 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.

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

[»]Hinweis

Üblicherweise ist es performanter, ein Spaltenelement über den Index astatt über den Spaltennamen zu erfragen. Gibt es zwei Spalten mit dem gleichen Namen, liefert die mit dem Namen aufgerufene Methode immer die erste Spalte.

 
Zum Seitenanfang

21.6.3Java und SQL-Datentypen Zur vorigen ÜberschriftZur nächsten Überschrift

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 einer String-Spalte die getInteger(…)-Methode auszuführen. Umgekehrt lassen sich alle Datentypen als String auslesen. Tabelle 21.4 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(…).

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

Tabelle 21.4Datentypen in SQL und ihre Entsprechung in Java

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. Ist ein Eintrag in der Datenbank mit NULL belegt, so liefert die Methode eine null-Referenz.

interface java.sql.ResultSet
extends Wrapper, AutoCloseable
  • String getString(int columnIndex)

  • String getString(String columnLabel)
    Liefert den Wert in der Spalte als Java-String.

  • boolean getBoolean(int columnIndex)

  • boolean getBoolean(String columnLabel)
    Liefert den Wert in der Spalte als Java-boolean.

  • byte getByte(int columnIndex)

  • byte getByte(String columnLabel)
    Liefert den Wert in der Spalte als Java-byte.

  • short getShort(int columnIndex)

  • short getShort(String columnLabel)
    Liefert den Wert in der Spalte als Java-short.

  • int getInt(int columnIndex)

  • int getInt(String columnLabel)
    Liefert den Wert in der Spalte als Java-int.

  • long getLong(int columnIndex)

  • long getLong(String columnLabel)
    Liefert den Wert in der Spalte als Java-long.

  • float getFloat(int columnIndex)

  • float getFloat(String columnLabel)
    Liefert den Wert in der Spalte als Java-float.

  • double getDouble(int columnIndex)

  • double getDouble(String columnLabel)
    Liefert den Wert in der Spalte als Java-double.

  • BigDecimal getBigDecimal(int columnIndex, int scale)

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

  • byte[] getBytes(int columnIndex)

  • byte[] getBytes(String columnLabel)
    Liefert den Wert in der Spalte als Byte-Feld. Es besteht aus uninterpretierten Rohdaten.

  • Date getDate(int columnIndex)

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

  • Time getTime(int columnIndex)

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

  • Timestamp getTimestamp(int columnIndex)

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

  • InputStream getAsciiStream(int columnIndex)

  • InputStream getAsciiStream(String columnLabel)
    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 columnIndex)

  • InputStream getBinaryStream(String columnLabel)
    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.

Alle getXXX(…)-Methoden können eine SQLException in dem Fall auslösen, dass etwas mit der Datenbank nicht stimmt. Der throws-Ausdruck ist also in der Aufzählung nicht explizit angegeben.

Aufzählung JDBCType, Schnittstelle SQLType in Java 8 *

Neu in Java 8 ist eine Aufzählung JDBCType, die knapp 40 JDBC-Typen enthält und mit ARRAY und BIGINT anfängt. Die Aufzählungstypen implementieren eine Schnittstelle SQLType, die ebenfalls neu ist in Java 8 und die Methoden getName(), getVendor() und getVendorTypeNumber() vorschreibt.

Mithilfe von SQLType ist es nun möglich, mit nur einer Methode alle möglichen SQL-Typen zu schreiben. So findet sich in der PreparedStatement-Methode in Java 8 setObject(int parameterIndex, Object x, SQLType targetSqlType), das dann die JDBC-spezifischen Typmethoden wie setArray(int parameterIndex, Array x), setBigDecimal(int parameterIndex, BigDecimal x), … ergänzt. Ähnliche Methoden haben ResultSet und CallableStatement.

 
Zum Seitenanfang

21.6.4Date, Time und Timestamp Zur vorigen ÜberschriftZur nächsten Überschrift

Datenbankseitig können Datumswerte in den SQL-Typen DATE, TIME und TIMESTAMP abgelegt sein:

  • DATE speichert ein Datum, also Tag, Monat und Jahr. Die Textrepräsentation hat die Form »YYYY-MM-DD«.

  • TIME speichert eine Zeit im 24-Stundenformat, also Stunden, Minuten und Sekunden. Sekunden können einen Sekundenbruchteil haben, sodass die Genauigkeit in die Nanosekunden geht. Die Darstellung ist »hh:mm:ss« bzw. »hh:mm:ss.nnnnnnn«.

  • TIMESTAMP verbindet DATE und TIME.

Unterschiedliche Datenbanken erlauben weitere Spezialitäten wie TIMESTAMP WITH TIME ZONE, was hier aber keine Rolle spielen soll.

Zur Abbildung der SQL-Typen auf Java sieht JDBC drei entsprechende Klassen vor:

SQL-Typ

Java-Klasse

DATE

java.sql.Date

TIME

java.sql.Time

TIMESTAMP

java.sql.Timestamp

Tabelle 21.5Datum-/Zeittypen in SQL und ihre Entsprechung in Java

Es fällt auf, dass alle drei JDBC-Klassen von der Basisklasse java.util.Date erben. Das hat unterschiedliche Konsequenzen. Im Einzelnen:

  • Die Klasse java.sql.Date repräsentiert das SQL-DATE. Die Basisklasse java.util.Date ist natürlich etwas merkwürdig und kollidiert mit dem liskovschen Substitutionsprinzip, da die Unterklasse Eigenschaften wegdefiniert, die die Oberklasse bietet. Denn ein java.util.Date ist ja für Datum und Zeit verantwortlich, wobei java.sql.Date nur Tag, Monat, Jahr speichert. Wenn also ein java.sql.Date mit Zeitinformationen gefüllt wird, so wird beim Abspeichern in die Datenbank diese Zeit auf null gesetzt. Das nennt die API-Dokumentation »Normalisierung«.

  • Die Klasse Time repräsentiert ein SQL-TIME. Die Basisklasse java.util.Date ist genauso widersprüchlich, denn hier wird der Datumsteil ausgeblendet, und nur der Zeitanteil ist erlaubt.

  • Für den SQL-Typ TIMESTAMP fasst die Java-Klasse Timestamp die Datums- und Zeitangaben mit einer Genauigkeit von Nanosekunden zusammen. Das ist wichtig zu beachten, denn bei einer Umwandlung eines Timestamp in ein java.util.Date gehen die Nanosekunden verloren, da java.util.Date diese Genauigkeit nicht bietet. Die Klasse Timestamp erbt von Date und fügt intern ein int nano-Attribut hinzu.

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-Deklaration 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( "birthday" );

Konvertierung von java.sql.Date in java.util.Date und umgekehrt

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 das Parsen mittels DateFormat nur ein java.util.Date liefert. Wir müssen also erst mit getTime() die Zeit erfragen und auf das SQL-DATE übertragen:

java.sql.Date sqlDate = new java.sql.Date( java_util_Date.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-Stil (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.

Aktualisierungen durch java.time-Inklusion in Java 8

In Java 8 berücksichtigt auch JDBC an wenigen Stellen Typen der neuen Datum- und Zeit-API aus dem Paket java.time, namentlich LocalDate, LocalTime, LocalDateTime und Instant. Neuen Methoden sind:

  • java.sql.Date: toLocalDate(), valueOf(LocalDate)

  • java.sql.Time: toLocalTime(), valueOf(LocalTime)

  • java.sql.Timestamp: toLocalDateTime(), valueOf(LocalDateTime), toInstant(), from(Instant)

 
Zum Seitenanfang

21.6.5Unicode in der Spalte korrekt auslesen Zur vorigen ÜberschriftZur nächsten Überschrift

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 Byte-Feld zu holen und dann ausdrücklich umzukodieren. Das Folgende ist etwa eine Lösung: new String(rs.getBytes(column), "ISO-8859–1").

 
Zum Seitenanfang

21.6.6Eine SQL-NULL und wasNull() bei ResultSet Zur vorigen ÜberschriftZur nächsten Überschrift

Ist der Wert einer Spalte eine SQL-NULL, so ist bei einer Abfrage mit der getXXX(…)-Methode Vorsicht geboten. Eine Methode wie getString(…) liefert standardmäßig null, und getInt(…), getLong(…), getFloat(…), getDouble(…) und weitere Methoden liefern 0; getBoolean(…) liefert ein false, und bei anderen Methoden sieht es ähnlich aus – keine Methode löst eine Ausnahme aus.

Die Behandlung von Nullwerten ist in JDBC recht ungewöhnlich gelöst. Wir würden erwarten, dass es eine Methode isNull(column) 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.

[zB]Beispiel

Die allgemeine Vorgehensweise für einen SQL-NULL-Test am Beispiel einer String-Abfrage ist:

String s = rs.getString( column );
if ( rs.wasNull() )
System.out.println( "SQL-NULL" );
interface java.sql.ResultSet
extends Wrapper, AutoCloseable
  • boolean wasNull()
    Ermittelt, ob die Spalte ein SQL-NULL enthält. Vorher muss eine getXXX()-Methode für die Spalte aufgerufen werden!

 
Zum Seitenanfang

21.6.7Wie viele Zeilen hat ein ResultSet? * Zur vorigen ÜberschriftZur nächsten Überschrift

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

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

Bei dieser Programmierung muss natürlich ein Treiber JDBC 2-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 Aufbau eines Statement-Objekts ein scrollbarer Cursor angemeldet werden:

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

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

 


Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück
 Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Java SE 8 Standard-Bibliothek Java SE 8 Standard-Bibliothek
Jetzt Buch bestellen

 Buchempfehlungen
Zum Rheinwerk-Shop: Java ist auch eine Insel
Java ist auch eine Insel


Zum Rheinwerk-Shop: Professionell entwickeln mit Java EE 8
Professionell entwickeln mit Java EE 8


Zum Rheinwerk-Shop: Besser coden
Besser coden


Zum Rheinwerk-Shop: Entwurfsmuster
Entwurfsmuster


Zum Rheinwerk-Shop: IT-Projektmanagement
IT-Projektmanagement


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo

 
 


Copyright © Rheinwerk Verlag GmbH 2018. Original - https://www.rheinwerk-verlag.de/openbook/
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

 

 
 


29.09.2022 - Sitemap.xml