✔ Auf Access Datenbank zugreifen

E

El Capitan

Grünschnabel
Hallo liebe Forengemeinde!

Nachdem ich nun schon einige Zeit mit meinem Problem verbracht habe und auch in diesem Forum schon zum gleichen Thema interessante Beiträge gelesen habe muss ich dieses Thema leider noch einmal neu aufrollen.

Ich versuche von meinem Rechner aus auf eine Datenbank zuzugreifen, die ebenfalls auf meinem Rechner liegt. Es funktioniert weder der Zugriff über einen eingerichteten DSN noch der Zugriff ohne DSN.



Über DSN und eine JDBC:ODBC Brücke bekomme ich folgenden Fehler
Java: 
private static Connection getConnection() throws Exception {
   String driver = "sun.jdbc.odbc.JdbcOdbcDriver";
   String url = "jdbc:odbc:hallo";
   String username = "";
   String password = "";
   Class.forName(driver);
   return DriverManager.getConnection(url, username, password);
}

Der angegebene DSN weist eine nicht übereinstimmende Architektur
von Treiber und Anwendung auf.
Warum? Könnte das Problem darin liegen, dass ich einen 32 Bit Treiber verwende und javaw.exe 64 Bit ist.



Der Versuch ohne DSN liefert folgendes Resultat
Java: 
private static Connection getConnection() throws Exception {
   String driver = "sun.jdbc.odbc.JdbcOdbcDriver";
   String url = "jdbc:odbc:Driver={Microsoft Access Driver " + "(*.mdb,*.accdb)};DBQ=...\\Test.accdb";
   Class.forName(driver);
   Connection con = DriverManager.getConnection(url);
   return DriverManager.getConnection(password);

Der Datenquellenname wurde nicht gefunden, und es wurde kein
Standardtreiber angegeben
Die Quelle ist definitv vorhanden und ich denke auch, dass der verwendete Treiber ok ist.



Probiert habe ich bereits folgendes:
  1. 32 Bit Treiber
    http://www.thomasschiffler.de/2010_...t-und-odbc-treiber-fur-access-endlich-gelost/
    -> Ich verwende in der DSN-Variante einen 32-Bit Treiber.
  2. Verwenden eines reinen JDBC-Treibers (bzw. Ersatzes)
    http://sourceforge.net/projects/jackcess/
    -> Will nicht, keine Ahnung warum. Ist hier aber nicht so wichtig.
  3. Unterschiedliche Connection Strings
    http://www.connectionstrings.com/access


Ich vermute, dass das alles irgendwie mit den unterschiedlichen verwendeten Architekturen zusammen hängt. Einen Reim kann ich mir daraus aber allerdings nicht so recht machen.
javaw -> 64
windows -> 64
netbeans -> 32 (wobei das eigtl egal sein sollte)
treiber -> 64


Auf eine Oracle Datenbank kann ich ohne Probleme zugreifen. Nur hier scheitere ich erbärmlich. Wenn mir irgendjemand Hinweise darauf hätte warum das ganze nicht tut wie ich es gerne hätte wäre ich der glücklichste Mensch der Welt :)

Umgebung:
Win 7 x64
Netbeans 6.9.1
JDK 1.6
Access 2007
 
Zuletzt bearbeitet:
So Hallo nochmal,
habe gestern testweise noch versucht mit einer 32 Bit JDK zu arbeiten. Und siehe da - alles gut. Zumindest auf den ersten Blick. Über meine Netbeans IDE lässt sich der Zugriff ohne DSN nun problemlos ausführen und ich kann auf die Datenbank zugreifen. Will ich das ganze nun aber über die Konsole starten tritt der gleiche Fehler wie zuvor auf. -> Ich sehe viele Fragezeichen aber keinen Sinn.

Ich starte das Programm mit "java -jar Dateiname". Muss ich hierbei noch irgendetwas berücksichtigen? Bzw. wo ist die Plattformunabhängigkeit hin? Vielleicht stehe ich ja auch auf dem Schlauch und habe nicht richtig verstanden wie Java (also die Zusammenarbeit zw. VM und Betriebssystem usw.) richtig funktioniert.

Würde mich freuen, wenn mich jemand auf den richtigen Weg führen könnte.
 
Moin und herzlich willkommen hier ^^

In wie fern die Bussbreite (32bit, 64bit) eine Rolle spielt und ob es dadurch knallt, kann ich nicht sagen, da ich immer nur die 32bit Version installiere, egal ob auf einer 32bit oder auf einer 64bit Maschine. Ich bezweifel jedoch, dass es zwischen den beiden Versionen Inkompatibilitäten gibt, denn beide erzeugen den selben Bytecode und werten ihn auch gleich aus, sonst wär das Ganze ja sinnfrei.

Zum Kommandozeilenaufruf: Hast du beim Export auch eine Main-Klasse eingestellt? In der Jar-Datei muss dafür im Ordner META-INF die Datei MANIFEST.MF existieren mit entsprechenden Einträgen, wie Main-Klasse, Classpath, usw.
Code: 
java -jar <jar>
macht nämlich nix anderes als in der Manifest-Datei nach der Main-Klasse zu suchen und diese zu starten. Ist aber nix angegeben, muss man den Aufruf dennoch von Hand machen.
Code: 
java -cp .;<jar> das.package.Klasse

Und wenn du auf eine Access-Datenbank zugreifen möchtest, dann könnte es vielleicht schon sein, dass du damit selbst dein Programm an eine Windows-Plattform bindest, bin mir aber nicht sicher. Kann sein, dass auch Unix-Systeme damit klar kommen, hab das nie getestet.
 
Wenn du eine 32Bit JRE und eine 64Bit JRE installiert hast, solltest du überprüfen, welche von beiden Versionen über die Konsole gestartet wird.
Code: 
java -version
sollte dir diese Frage beantworten. ggf. musst du dann ins Verzeichnis der richtigen JRE wechseln oder den Pfad der richtige JRE angeben.
Und die Plattformunabhängigkeit ist noch gegeben – war sie aber noch nie bei der Verwendung nativer Bibliotheken/nativen Codes. Und es ist nun mal so, dass man unter Windows nicht 32Bit-Code und 64Bit-Code in einem Prozess ausführen kann, daran muss sich auch die JRE halten.
 
@bugmenot2: Wie gesagt, eine 64Bit JVM kann keinen 32Bit nativen Code aufrufen. Und umgekehrt gibt es das gleiche Problem.
 
So Hallo und Danke an alle!!

Die Lösung des Problems hat genodeftest geliefert. Ich habe zwar sowohl die 32 Bit als auch die 64 Bit JRE-Variante installiert. Über die Konsole wurde aber die 64 Bit Version ausgeführt, wodurch es dann zu den entsprechenden Fehlern kam. Ursprünglich ging ich iwie naiv davon aus, dass die JVM den Unterschied selber bemerkt und dann sich selber in der entsprechenden Version startet, was ja eigentlich an sich schon falsch ist, weil sie ja schon gestartet sein müsste um sich selber zu starten... Auf jeden Fall mal wieder was gelernt und vielleicht dem ein oder anderen verzweifeltes suchen erspart.

Bei mir sieht das ganze in der Konsole dann wie folgt aus:
Code: 
C:\Program Files (x86)\Java\jre7\bin\java.exe -jar ~\prog.jar
Wobei die java.exe die 32 Bit Version darstellt!!

Nocheinmal vielen Dank an alle und bis zum nächsen Problem.
 
Nur so als Tipp: Entweder du schmeißt eine der Versionen runter und trägst dann die richtige im PATH ein oder aber du legst für die jeweilige Version eine eigene Umgebungsvariable an (JRE_32, JRE_64 oder sowas), weil ich würde nicht den ganzen Pfad da runterrattern wollen. Durch die Änderung würde dann sowas entstehen:
Code: 
%JRE_32%\bin\java -jar <Jardatei>
Ich kenne den Pfad zwar auswendig, aber so einen Pfad eintippen zu müssen ist alles andere als angenehm.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück