Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

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

Buch bestellen
Ihre Meinung?

Spacer
Java 7 - Mehr als eine Insel von Christian Ullenboom
Das Handbuch zu den Java SE-Bibliotheken
Buch: Java 7 - Mehr als eine Insel

Java 7 - Mehr als eine Insel
Rheinwerk Computing
1433 S., 2012, geb.
49,90 Euro, ISBN 978-3-8362-1507-7
Pfeil 16 Datenbankmanagement mit JDBC
Pfeil 16.1 Relationale Datenbanken
Pfeil 16.1.1 Das relationale Modell
Pfeil 16.2 Datenbanken und Tools
Pfeil 16.2.1 HSQLDB
Pfeil 16.2.2 Weitere Datenbanken *
Pfeil 16.2.3 Eclipse-Plugins zum Durchschauen von Datenbanken
Pfeil 16.3 JDBC und Datenbanktreiber
Pfeil 16.3.1 Treibertypen *
Pfeil 16.3.2 JDBC-Versionen *
Pfeil 16.4 Eine Beispielabfrage
Pfeil 16.4.1 Schritte zur Datenbankabfrage
Pfeil 16.4.2 Ein Client für die HSQLDB-Datenbank
Pfeil 16.4.3 Datenbankbrowser und eine Beispielabfrage unter NetBeans
Pfeil 16.5 Mit Java an eine Datenbank andocken
Pfeil 16.5.1 Der Treiber-Manager *
Pfeil 16.5.2 Den Treiber laden
Pfeil 16.5.3 Eine Aufzählung aller Treiber *
Pfeil 16.5.4 Log-Informationen *
Pfeil 16.5.5 Verbindung zur Datenbank auf- und abbauen
Pfeil 16.6 Datenbankabfragen
Pfeil 16.6.1 Abfragen über das Statement-Objekt
Pfeil 16.6.2 Ergebnisse einer Abfrage in ResultSet
Pfeil 16.6.3 Java und SQL-Datentypen
Pfeil 16.6.4 Date, Time und Timestamp
Pfeil 16.6.5 Unicode in der Spalte korrekt auslesen
Pfeil 16.6.6 Eine SQL-NULL und wasNull() bei ResultSet
Pfeil 16.6.7 Wie viele Zeilen hat ein ResultSet? *
Pfeil 16.7 Elemente einer Datenbank hinzufügen und aktualisieren
Pfeil 16.7.1 Batch-Updates
Pfeil 16.7.2 Die Ausnahmen bei JDBC, SQLException und Unterklassen
Pfeil 16.8 ResultSet und RowSet *
Pfeil 16.8.1 Die Schnittstelle RowSet
Pfeil 16.8.2 Implementierungen von RowSet
Pfeil 16.8.3 Der Typ CachedRowSet
Pfeil 16.8.4 Der Typ WebRowSet
Pfeil 16.9 Vorbereitete Anweisungen (Prepared Statements)
Pfeil 16.9.1 PreparedStatement-Objekte vorbereiten
Pfeil 16.9.2 Werte für die Platzhalter eines PreparedStatement
Pfeil 16.10 Transaktionen
Pfeil 16.11 Metadaten *
Pfeil 16.11.1 Metadaten über die Tabelle
Pfeil 16.11.2 Informationen über die Datenbank
Pfeil 16.12 Vorbereitete Datenbankverbindungen
Pfeil 16.12.1 DataSource
Pfeil 16.12.2 Gepoolte Verbindungen
Pfeil 16.13 JPA-Beispiel mit der NetBeans-IDE
Pfeil 16.13.1 Entity-Beans generieren
Pfeil 16.13.2 Die Quellen im Überblick
Pfeil 16.13.3 Persistence Unit
Pfeil 16.13.4 Ein JPA-Beispielprogramm
Pfeil 16.14 Zum Weiterlesen

Rheinwerk Computing - Zum Seitenanfang

16.7 Elemente einer Datenbank hinzufügen und aktualisierenZur nächsten Überschrift

Bisher haben wir executeQuery() benutzt, um Abfragen zu verfassen. Es lassen sich jedoch auch Einfüge-Operationen vornehmen, denn Tabelleninhalte bleiben nicht unveränderlich.

Das SQL-Kommando INSERT fügt Daten ein, und UPDATE aktualisiert sie. Damit Spalten verändert werden können, müssen wir in zwei Schritten vorgehen:

  1. eine SQL-Anweisung mit einem UPDATE aufbauen und
  2. anschließend executeUpdate() aufrufen.

Damit wird die Änderung wirksam. Dies ist eine andere Statement-Methode, bisher kannten wir nur executeQuery(). Neben den Methodennamen gibt es aber noch einen anderen Unterschied: executeUpdate() liefert als Rückgabewert ein int, das angibt, wie viele Zeilen von der Änderung betroffen sind.

Beispiel

Folgende SQL-Anweisung ändert die Adresse eines Lieferanten einer fiktiven Relation:

String updateString = "UPDATE Lieferanten SET Adresse = " +
"'Uferstraße 80' WHERE Adresse LIKE 'Uferstrasse 78'";
stmt.executeUpdate( updateString );

Die Methode gibt uns immer zurück, wie viele Zeilen von den Änderungen betroffen sind. Sie ist 0, falls das SQL-Statement nichts bewirkt.

interface java.sql.Statement
extends Wrapper, AutoCloseable
  • int executeUpdate(String sql) throws SQLException
    Führt eine SQL-Anweisung aus, die Manipulationen an der Datenbank vornimmt. Die SQL-Anweisungen sind in der Regel INSERT-, UPDATE- oder DELETE-Anweisungen. Zurückgegeben wird die Anzahl der veränderten Zeilen, oder null, falls eine SQL-Anweisung nichts verändert hat.

Rheinwerk Computing - Zum Seitenanfang

16.7.1 Batch-UpdatesZur nächsten ÜberschriftZur vorigen Überschrift

Das Einfügen und Ändern großer Mengen von Daten kostet viel Zeit, da für jede Modifikation ein INSERT oder UPDATE über ein Statement-Objekt abgewickelt werden muss. Eine Verbesserung stellen Batch-Updates dar, die in einem Rutsch gleich eine ganze Reihe von Daten zur Datenbank transferieren. Statt mit execute() und deren Varianten zu arbeiten, nutzen wir die Methode executeBatch(). Damit zuvor die einzelnen Aktionen dem Statement-Objekt mitgeteilt werden können, bietet die Klasse die Methoden addBatch() und clearBatch() an. Die Datenbank führt die Anweisungen in der Reihenfolge aus, wie sie im Batch-Prozess eingefügt wurden. Ein Fehler wird über eine BatchUpdateException angezeigt.

Beispiel

Wir fügen einige Einträge der Datenbank als Batch hinzu. con sei unser Connection-Objekt:

int[] updateCounts = null;
try
{
Statement s = con.createStatement();
s.addBatch( "INSERT INTO Lieferanten VALUES (x,y,z)" );
s.addBatch( "INSERT INTO Lieferanten VALUES (a,b,c)" );
s.addBatch( "INSERT INTO Lieferanten VALUES (d,e,f)" );
updateCounts = s.executeBatch();
}
catch ( BatchUpdateException e ) { /* Behandeln! */ }
catch ( SQLException e ) { /* Behandeln! */ }

Nach dem Abarbeiten von executeBatch() erhalten wir als Rückgabewert ein int-Feld mit den Ergebnissen der Ausführung. Dies liegt daran, dass in der Batch-Verarbeitung ganz unterschiedliche Anweisungen vorgenommen werden können und jede davon einen unterschiedlichen Rückgabewert verwendet.

Soll der gesamte Ablauf als Transaktion gewürdigt werden, so setzen wir im try-Block den AutoCommit-Modus auf false, damit nicht jede SQL-Anweisung als einzelne Transaktion gewertet wird. Im Fall eines Fehlers müssen wir im catch-Block ein Rollback ausführen. Übertragen wir dies auf das obere Beispiel, dann müssen nur die beiden Anweisungen für die Transaktion eingesetzt werden:

try
{
con.setAutoCommit( false );
Statement s .....
...
}
catch ( BatchUpdateException e )
{
con.rollback();
}

Rheinwerk Computing - Zum Seitenanfang

16.7.2 Die Ausnahmen bei JDBC, SQLException und UnterklassenZur nächsten ÜberschriftZur vorigen Überschrift

Normale Ausnahmen in Java tragen lediglich eine Nachricht, die sich mit getMessage() erfragen lässt. Da bei Datenbanken aber viele Dinge schiefgehen können, hätten die Architekten der JDBC-API viel zu tun, wenn sie für jede mögliche Ausnahme eine Exception-Klasse bereitstellen wollten. Doch wegen der schier unüberschaubaren Anzahl an Fehlern haben sie sich für ein anderes Modell entschieden.

JDBC-Fehlerbasisklasse SQLException

Zunächst einmal gibt es für JDBC-Ausnahmen den Basistyp SQLException. Zusätzlich speichert jedes SQLException-Objekt Fehlercodes, die der JDBC-Treiber der Datenbank setzen und so über den konkreten Fehler informieren kann.

Die genauen Informationen einer SQL-Ausnahme sind über drei Methoden zugänglich:

  • String getMessage(): eine textuelle Beschreibung des Fehlers
  • String getSQLState(): Einen String mit dem SQL-Status. Hier gibt es zwei Konventionen. Einmal kann es ein SQL-Status nach der SQL-CLI-Spezifikation der Open Group (vor über zehn Jahren hieß sie X/Open) sein – oder ein SQL:2003-Code. Beide sind datenbankunabhängig. Nach welcher Spezifikation der Code formuliert ist, sagt die Methode getSQLStateType() vom DatabaseMetaData-Objekt. Der Open-Group-Standard ist üblich.
  • int getErrorCode(): Ein Fehler-Code vom JDBC-Treiber. Er kommt vom Hersteller der Datenbank bzw. vom Datenbanktreiber. Er ist datenbankabhängig.

Der Open-Group-SQL-Status ist eigentlich eine Zahl, aber als String verpackt. Im Optimalfall ist der Code »00000«, was »Alles paletti« heißt. Die ersten beiden Ziffern stehen für die Fehlerklasse. 01 ist eine Warnung, 02 sagt, dass Daten fehlen, usw.[101](Unter ftp://ftp.software.ibm.com/ps/products/db2/info/vr6/htm/db2m0/db2state.htm bekommen Leser einen Überblick.)

Eine Verkettung unglücklicher Tatsachen

Eine SQLException hat eine Besonderheit, die sonst keine Ausnahme in der Java-Bibliothek aufweist. Sie implementiert die Schnittstelle Iterable<Throwable>:

class java.sql.SQLException
extends Exception
implements Iterable<Throwable>

Das heißt, dass eine SQLException ein Bündel von Ausnahmen repräsentieren kann und nicht nur genau eine. Welche JDBC-Ausnahmen noch an der SQLException hängen, liefert getNextException() bzw. steckt im Iterator der SQLException.

Beispiel

Laufe alle Fehler ab:

try { ... }
catch ( SQLException e )
{
for ( ; e != null; e = e.getNextException() )
{
System.err.println( "Message: " + e.getMessage() );
System.err.println( "SQL State: " + e.getSQLState() );
System.err.println( "Error Code: " + e.getErrorCode() );
}
}

SQLWarning

Nicht jeder Fehler bzw. jede Meldung der Datenbank ist gleich ein kritischer Fehler, der zum Abbruch der Datenbankoperationen führt. Die JDBC-API bietet mit der Klasse SQLWarning eine besondere Unterklasse von SQLException, doch wird sie nicht als Exception ausgelöst, sondern muss im Programm explizit über getWarnings() geholt werden. Die Typen Connection, ResultSet und Statement deklarieren diese Operation. Im besten Fall holen sich Entwickler alle Warnungen und loggen sie.

Da die SQLWarning eine SQLException ist, ist auch die Verarbeitung von SQL-Code und Fehlercode gleich. Anstatt jedoch mit getNextException() zu arbeiten, bietet SQLWarning die Methode getNextWarning() um zur nächsten Warnung vorzustoßen. Werden die Meldungen nicht geholt, dann werden sie bei der Ausführung der nächsten SQL-Anweisung gelöscht.

Daten fehlen

Für den SQL-Status »01004« und »22001« gibt es eine eigene Fehlerklasse, die DataTruncation. Sie ist ein spezieller Typ einer SQL-Warnung und wird immer dann erzeugt, wenn Daten während der Schreib- oder Leseoperationen verloren gingen. Die Meldung wird genauso geholt wie SQLWarning, nur wird mittels instanceof DataTruncation überprüft, ob es sich um DataTruncation handelt. Dies erfordert eine Typumwandlung von SQLWarning auf DataTruncation. Dann stehen Methoden wie getIndex() oder getTransferedSize() bereit, die aussagen, für welche Spalte wie viel Bytes korrekt übertragen wurden. DataTruncation ist die einzige Unterklasse von SQLWarning.

Abbildung

Abbildung 16.17: Vererbungshierarchie der JDBC-Fehlerklassen



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück
  Zum Katalog
Neuauflage: Java SE 8 Standard-Bibliothek
Neuauflage: Java SE 8 Standard-Bibliothek
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Professionell entwickeln mit Java EE 7






 Professionell
 entwickeln mit
 Java EE 7


Zum Katalog: Java ist auch eine Insel






 Java ist auch
 eine Insel


Zum Katalog: Einstieg in Eclipse






 Einstieg in Eclipse


Zum Katalog: Einstieg in Java






 Einstieg in Java


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2012
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das 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.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de