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
Download: - openbook, ca. 21,3 MB
Buch bestellen
Ihre Meinung?
<< zurück | Galileo Computing / <openbook> / Java 7 - Mehr als eine Insel | vor >>
Java 7 - Mehr als eine Insel von Christian Ullenboom Das Handbuch zu den Java SE-Bibliotheken
Java 7 - Mehr als eine Insel Galileo Computing 1433 S., 2012, geb. 49,90 Euro, ISBN 978-3-8362-1507-7 |
| 16 Datenbankmanagement mit JDBC
|  | 16.1 Relationale Datenbanken
|  |  | 16.1.1 Das relationale Modell
|  | 16.2 Datenbanken und Tools
|  |  | 16.2.1 HSQLDB
|  |  | 16.2.2 Weitere Datenbanken *
|  |  | 16.2.3 Eclipse-Plugins zum Durchschauen von Datenbanken
|  | 16.3 JDBC und Datenbanktreiber
|  |  | 16.3.1 Treibertypen *
|  |  | 16.3.2 JDBC-Versionen *
|  | 16.4 Eine Beispielabfrage
|  |  | 16.4.1 Schritte zur Datenbankabfrage
|  |  | 16.4.2 Ein Client für die HSQLDB-Datenbank
|  |  | 16.4.3 Datenbankbrowser und eine Beispielabfrage unter NetBeans
|  | 16.5 Mit Java an eine Datenbank andocken
|  |  | 16.5.1 Der Treiber-Manager *
|  |  | 16.5.2 Den Treiber laden
|  |  | 16.5.3 Eine Aufzählung aller Treiber *
|  |  | 16.5.4 Log-Informationen *
|  |  | 16.5.5 Verbindung zur Datenbank auf- und abbauen
|  | 16.6 Datenbankabfragen
|  |  | 16.6.1 Abfragen über das Statement-Objekt
|  |  | 16.6.2 Ergebnisse einer Abfrage in ResultSet
|  |  | 16.6.3 Java und SQL-Datentypen
|  |  | 16.6.4 Date, Time und Timestamp
|  |  | 16.6.5 Unicode in der Spalte korrekt auslesen
|  |  | 16.6.6 Eine SQL-NULL und wasNull() bei ResultSet
|  |  | 16.6.7 Wie viele Zeilen hat ein ResultSet? *
|  | 16.7 Elemente einer Datenbank hinzufügen und aktualisieren
|  |  | 16.7.1 Batch-Updates
|  |  | 16.7.2 Die Ausnahmen bei JDBC, SQLException und Unterklassen
|  | 16.8 ResultSet und RowSet *
|  |  | 16.8.1 Die Schnittstelle RowSet
|  |  | 16.8.2 Implementierungen von RowSet
|  |  | 16.8.3 Der Typ CachedRowSet
|  |  | 16.8.4 Der Typ WebRowSet
|  | 16.9 Vorbereitete Anweisungen (Prepared Statements)
|  |  | 16.9.1 PreparedStatement-Objekte vorbereiten
|  |  | 16.9.2 Werte für die Platzhalter eines PreparedStatement
|  | 16.10 Transaktionen
|  | 16.11 Metadaten *
|  |  | 16.11.1 Metadaten über die Tabelle
|  |  | 16.11.2 Informationen über die Datenbank
|  | 16.12 Vorbereitete Datenbankverbindungen
|  |  | 16.12.1 DataSource
|  |  | 16.12.2 Gepoolte Verbindungen
|  | 16.13 JPA-Beispiel mit der NetBeans-IDE
|  |  | 16.13.1 Entity-Beans generieren
|  |  | 16.13.2 Die Quellen im Überblick
|  |  | 16.13.3 Persistence Unit
|  |  | 16.13.4 Ein JPA-Beispielprogramm
|  | 16.14 Zum Weiterlesen
## 16.7 Elemente einer Datenbank hinzufügen und aktualisieren 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: eine SQL-Anweisung mit einem UPDATE aufbauen und 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. ### 16.7.1 Batch-Updates 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();
    }
### 16.7.2 Die Ausnahmen bei JDBC, SQLException und Unterklassen 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 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 | <top> | vor >>
Zum Katalog
Java 7 – Mehr als eine Insel Jetzt bestellen
Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen? Ihre Meinung
Buchempfehlungen
| Java und XML
| Einstieg in Eclipse 3.7
| Android 3
| NetBeans Platform 7
| Java ist auch eine Insel
| Apps entwickeln für Android 4
| Java 7
Shopping
Versandkostenfrei bestellen in Deutschland und Österreich Info

Copyright © Galileo Press 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.

[Galileo Computing]
Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de