Woran erkenne, was beim SQL passiert ist ?

[kuddelmuddel123]

Hallo,

ich möchte im Java-Programm mit SQL auf eine MySQL-Datenbank zugreifen.
Woran kann ich erkennen, ob der SQL-Befehl geklappt hat bzw. wenn er nicht geklappt hat, warum nicht ?

Bisher habe ich viel mit der Sprache C und SQL zum Zugriff auf DB2 gearbeitet. Dort habe ich nach einem SQL-Befehl den SQL-Code zurückbekommen, der eindeutig zu interpretieren war.
z.B. -911 = Timeout, -803 = beim Insert Satz in DB2 schon vorhanden

Wie mache ich entsprechendes in Java ?
Ich habe gesehen, daß im Fehlerfall eine SQLException da ist. Doch darin habe ich nur einen Errorcode, von dem ich nicht weiß, was er besagt (außer daß er herstellerspezifisch ist) und einen SQLState, der ein String ist.
Gibt es irgendwo eine Übersicht, was sich hinter diesen beiden Werten "versteckt" ?
Kann ich z.B. rauslesen, daß ein Timeout passiert ist / beim Insert der Satz schon da war ?

Vielen Dank für die Hilfe !

 

[limago]

Hi,

Das ist eine nicht so ganz einfache Frage. Da in der Tat die Hersteller keinen einheitlichen Fehlersatz haben, kann man das so tatsächlich nicht lösen. Noch schlimmer wird es, wenn die Datenquelle, neben einer SQL-Datei auch eine XML Datei oder irgendein Legacy-System sein können. Dann fliegen nicht mal SQL-Exceptions.

Deshalb entkoppelt man die konkrete Persistenz von der Geschäftslogik. Die GL sollte gar nichts von solchen Details wissen, da man die Persistenz sonst nicht tauschen kann.

Bei Microsoft heisst ein solche Layer der die konkrete Persitenz entkoppelt DACL, bei Java spricht man meist von einer DAO-Schicht (Data Access Object). Die sollte unabhängig von der verwendeten Speicherphysik immer die selben (DAO) - Exceptions liefern. Wenn ich Zeit habe stelle ich morgen mal ein Beispiel ein.

Wenn Du Dich auf SQL festlegst, würde ich einen OR-Mapper wie Hibernate oder so was ähnliches benutzen. Das löst viele Probleme und macht Dich von der Datenbank völlig unabhängig,

Bin etwas in Eile, später mehr

Gruss

 

[Thomas Darimont]

Hallo,

Java 6 bietet eine erweiterte SQLException-Hierarchie an mit der man
etwas spezieller auf Datenbankausnahmen reagieren kann.
SQLTransientException -> Eine Aktion die dieses mal schief ging könnte das nächste mal funktionieren (beispiel Update auf eine gelockedte Tabelle -> Lock könnte mittlerweile aufgehoben sein)

SQLRecoverableException -> Eine Aktion die dieses mal schief ging könnte das nächste mal funktionieren, wenn bestimmte Aktionen wieder rückgangig gemacht (anlegen eines FK COnstraint...) und dann wieder erneut durchgeführt werden.

SQLNonTransierenException -> Aktion wird in jedem Fall fehlschlagen bei erneuten versuchen...

Viele Frameworks / Systeme (wie beispielsweise Springframework / Hibernate / JBoss) arbeiten auch mit
sogenannten Exception Translator Patterns. D.h. dass eine Datenbankspezifsche Exception (die einen Datenbankspezifischen SQL ErrorCOde enthält) auf eine spezifische Framework-Exception abegebildet wird, die die Ausnahmebehandlung einfacher gestaltet. Beispiele wären hier die BadSqlGrammarException des Springframeworks die immer dan geworfen wird wenn der entsprechende JDBC Treiber einen Fehler mit der Syntax des SQL Statements in Verbindung bringt (die entsprechenden Fehlercodes der einzelnen JDBC Treiber werden auf die BadGrammarSQLException gemapped).
Das vereinfacht die Ausnahmebehandlung ungemein.

Gruß Tom