Java – MySql – Beim Insert die angelegte ID des Primary Keys zurück bekommen

Beim Programmieren hatte ich eine für mich neue Anforderung: Ich wollte direkt nach dem Insert in die Datenbank den Primary Key des angelegten Datensatzes zurück bekommen. Die Lösung fand sich schnell im Netz und ich will sie aber für zukünftige Recherchen meinerseits gleich hier in meinem „Knowledge-Fundus“ hier hinterlegen:

String insertQuery = "INSERT INTO TABLE (…) VALUES (?,?,?)";
PreparedStatement ps = db.prepareStatement(query, Statement.RETURN_GENERATED_KEYS);
ps.setInt(1,…);
ps.setInt(2,…);
ps.setInt(3,…);
ps.execute();
ResultSet rs = ps.getGeneratedKeys();
Integer idPrimarykey = null;
if (rs.next()){
idPrimarykey=rs.getInt(1);
}
return idPrimarykey; 

Das Kommando klappt in meinem Beispiel hervorragend mit MySql. Damit konnte ich diekt aus dem Insert den Primary Key ermitteln und direkt weiterverarbeiten.

Nicht druckbare Zeichen in Java Strings lassen .equal oder .valueOf(String) fehlschlagen

Beim Vergleichen von Strings mit equal oder Enum Parsen mit „valueOf“ gibt es keinen match, obwohl der String augenscheinlich identisch ist – Dieses Problem wird in diesem Beitrag erläutert:

Beim Parsen von CSV Dateien stößt man ab und zu auf Probleme mit der Encodierung der zu parsenden Datei.

Im konkreten Fall gestaltete sich das Problem als herausfordernd, weil auf den ersten Blick keine Ursache für das Problem erkennbar war.

Die geparste Variable nennt sich „rowTypeString“ und hat im Debugger den Inhalt „RH“

debug screenshot - String "RH" sieht aus als wäre er 2 Zeichen lang, ist aber 3 Zeichen lang wegen nicht druckbarer Zeichen - aus diesem Grund schlägt ein Equal fehl
Augenscheinlicher Inhalt der Variable „rowTypeString“ – nur zwei Zeichen mit dem Inhalt „RH

Im Quelltext wird jedoch die Variable über ein Enum mit der  „valueOf()“-Funktion geparst und einem eindeutigen Typ zugewiesen. Diese lief jedoch immer auf eine IllegalArgumentException hinaus.
Die Analyse des String ergab dann doch noch interessante Details:

  • Der String hat eine Länge von 3 Zeichen (auch wenn das dritte unsichtbar ist)
  • Ein Character Array gab auch interessante Details zurück:
char of string with hidden character
  • Die Methode rowTypeString.getBytes() gibt  zahlreiche Bytes zurück, welche auf das dritte Zeichen hindeuten:
    [-17, -69, -65, 82, 72]
  • Eigentlich dürfte das ByteArray nur [82,72] lauten für den String „RH“

Die Lösung konnte sich dann doch gut sehen lassen. Es werden alle „nicht druckbaren Zeichen“ entfernt mit dem nachfolgenden regulären Ausdruck:

stringValue.replaceAll("[^\\p{Graph}\n\r\t ]", "");

Ich danke an dieser Stelle dem Verfasser einer Antwort in StackOverFlow

Eclipse debug stoppt auch ohne eigene Breakpoints

Java-Entwickler, welche mit Eclipse arbeiten, erhalten manchmal nach einem Update von Eclipse oder der Java VM Debugfehler, welche sich nicht auf die eigenen Projektdateien beziehen, sondern auf Breakpoints im Java JDK:

Thread [main] (Suspended (exception FileNotFoundException))
URLClassPath$JarLoader.getJarFile(URL) line: 577
URLClassPath$JarLoader. (URL, URLStreamHandler, HashMap) line: 546
URLClassPath$3.run() line: 324
AccessController.doPrivileged(PrivilegedExceptionAction ) line: not
available [native method]
URLClassPath.getLoader(URL) line: 313
URLClassPath.getLoader(int) line: 290
URLClassPath.getResource(String, boolean) line: 160
URLClassPath.getResource(String) line: 213

17-02-_2016_15-35-00

Auch langes googlen hat mir diesmal nicht geholfen. Meistens gab es Empfehlungen, in den Preferences –> Debug  „Suspend execution on uncaught exceptions“ zu deaktivieren.

17-02-_2016_15-32-29Leider hatte das bei mir nicht geholfen. Was allerdings half, war bei Breakpoints die betroffene Klasse zu deaktivieren bzw. das Häkchen von „Caught locations“ zu deaktivieren.

17-02-_2016_11-20-16Ich hoffe, auch Euch hilft dieser Tipp.

 

Java ODBC-Zugriff auf x64-Windows / Advantage Database Server

64 Bit ist ein Trend, der nicht mehr aufzuhalten ist. Endlich ist die 3GB-Grenze auf den Clientbetriebssystemen Geschichte.
Mit Windows 7×64 habe ich auch meine Programmierumgebung auf 64 Bit umgestellt – damit gingen meine Probleme los.

Bisher habe ich mit Java und ODBC auf meine ADS-DBF-Dateien zugegriffen mit folgender Konfiguration:

Unter Windows 7 funktionierte die Datenbankanbindung jedoch nicht mehr. Erste Hürde: Installation eines 32-Bit ODBC-Treibers.
Es gibt unter Windows 7 64 Bit die ODBC-Verwaltung in 32 und in 64 Bit:

ODBC Datenquellenadministrator 32 Bit:
c:\windows\SysWOW64\odbcad32.exe

ODBC Datenquellenadministrator 64 Bit:
c:\windows\System32\odbcad32.exe

Die ODBC-Verbindung klappt jedoch nur in Kombination mit 32 Bit Java und 32 Bit ODBC. Auf reiner 64-Bit Ebene funktioniert die Verbindung nicht.
Es kommt folgende Fehlermeldung:

java.sql.SQLException: [Microsoft][ODBC Driver Manager] Der angegebene DSN weist eine nicht übereinstimmende Architektur von Treiber und Anwendung auf.
at sun.jdbc.odbc.JdbcOdbc.createSQLException(Unknown Source)
at sun.jdbc.odbc.JdbcOdbc.standardError(Unknown Source)
at sun.jdbc.odbc.JdbcOdbc.SQLDriverConnect(Unknown Source)
at sun.jdbc.odbc.JdbcOdbcConnection.initialize(Unknown Source)
at sun.jdbc.odbc.JdbcOdbcDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
at rentasad.lib.db.ODBCConnection.connect(ODBCConnection.java:68)
at rentasad.lib.db.ODBCConnection.(ODBCConnection.java:29)
at rentasad.main.KreditkartenZuDTIGenerator.main(KreditkartenZuDTIGenerator.java:45)

Diese Fehlermeldung lässt sich jedoch ziemlich einfach beheben.

Es muss ein 32 Bit JDK installiert werden. Dieses wird zum Ausführen der Java-Applikation verwendet.
Einrichtung eines 32-Bit SDKs für eine Applikation