JDBC-Treiberklasse

[MaddinR]

Hallo liebe Leute

Warum sagt mir OOo immer, dass er den JDBC-Treiber nicht laden konnte? OK, dazu ein paar Infos:

OS = Win 7
OOo = 3.3.0
DB = SQLite 3 (c:\Java\test.sdb)
Treiber = SqliteJDBC (c:\Java\sqlitejdbc-v056.jar von http://www.zentus.com/sqlitejdbc

Ich habe zum Testen auf C:\ ein Verzeichnis "Java" eingerichtet, die Datei sqlitejdbc-v056.jar dort reinkopiert,
ebenso meine Test-DB und in OOo unter Optionen-Java "C:\Java" als Class-Path eingetragen. Beim Verbinden
zur bestehenden Datenbank in OOo trage ich folgendes ein:
Daten-URL: jdbc:c:\Java\Test.sdb
JDBC-Treiberklasse: org.sqlite.JDBC

Und wenn ich dann "Klasse Testen" anklicke lautet die Antwort "Kann Treiber nicht laden"

Was mache ich denn da verkehrt?

Danke für Eure Hilfe!

vg, Maddin

[gogo]

hab' keine Ahnung von SQLite, aber wenn Du eine *.jar verwendest, dann solltest Du im Classpath nicht den Pfad, sondern das jar-Archiv hinzufügen.

C:\Java\sqlitejdbc-v056.jar

(Extras/Optionen/Openoffice/Java/ClassPath/Archive hinzufügen)

g

[MaddinR]

Hallo

Ja, das hat geklappt... Treibertest war erfolgreich. Die Verbindung zur Datenbank war dann ebenfalls erfolgreich.

Aber die wirklich einfach Abfrage "SELECT * FROM Umsatz" führte dann zu folgendem Ergebnis: "SQLite only supports TYPE_FORWARD_ONLY cursors". Keine Ahnung, was das soll, unter ODBC funktionierte das tadellos

Ich habe für weitere Test's dann von Ch.Werner den JDBC-Treiber runtergeladen und auf gleichem Wege "eingerichtet". Treibertest war sofort erfolgreich, allerdings gelingt es mir damit überhaupt nicht, die DB zu öffen, bzw. eine Verbindung zur DB aufzubauen. Ich habe auch -wie angegeben- die sqlite_jni.dll in beide Java-Verzeichnisse kopiert, in c:\Programme\Java\jre6\bin und c:\Programme\Java\jre6\lib. Aber es klappt einfach nicht.
Nachtrag: Ich habs gerade hingekriegt, mit dem Ch.-Werner-Treiber die DB zu öffen... es fehlte ein "/" hinter "sqlite" in der Url: sqlite:/m:\OOo\Test\Umsatz.sdb. Aber es passiert genau das gleiche, beim einfachsten "SELECT * FROM Umsatz" kommt eine Fehlermeldung "Not supported"

Irgendeine Idee?

vg, Maddin

ps
Warum bleib ich nicht bei ODBC, wenns doch funktioniert... ?... weil ODBC auch nur unbefriedigend funktioniert .... Die Umlaute Ü und Ö werden nicht dargestellt, obwohl sie korrekt in der DB enthalten sind. SQLiteStudio und das PlugIn für Firefox zeigen die Daten jedoch korrekt an - nur ODBC in Verbindung mit OOo hat Probleme. Und ich meine irgendwo gelesen zu haben, dass das bei JDBC fehlerfrei sein soll.

[komma4]

Die Abfragesyntax ist abhängig vom Treiber.

Versuche mal ein

Code: Alles auswählen

SELECT * FROM "Umsatz"

Klappt das?

[AndreasJBittner]

Hallo Maddin,

klar geht das mit ODBC, Du mußt nur dem ODBC-Treiber mitteilen, welchen Zeichensatz er nehmen soll und der muß zur Tabelle passen, also wenn für die DB UTF8 eingestellt ist, muß der Treiber das auch wissen, sonst bekommst Du für die Umlaute immer 2 Zeichen, und dem OOo/LO mußt Du es auch sagen, also an drei Stellen.

Grüße
Andreas

[MaddinR]

Halo liebe Leute

Danke für Eure Hilfe... aber bis jetzt war keine Lösung dabei ... und mittlerweile frustriert mich das jetzt schon ziemlich nach 1 erfolglosen Woche....

Also.... was geht und was nicht....?

Ich habe von Ch. Werner alle 3 ODBC-Treiber getestet. Interessant ist, wenn ich den UTF8-Treiber verwende, lautet die Verbindungsantwort: "Keine Datenbank oder verschlüsselt". Natürlich habe ich vorher mit dem Firefox-Plugin controlliert, wie die DB selber eingestellt ist... die steht auf UTF8.... *hmmm* ... Der zweite Treibe ohne weitere Angaben im Namen funktioniert ebensowenig, die Antwort beim Verbindungsaufbau ist zumindest die gleiche.

Lediglich der Default SQLite3-Treiber funktioniert und kann die DB und die Tables handhaben, allerdings fehlen dabei die Umlaute... das heisst, das Zeichen fehlt völlig und es wird auch nichts anderes stattdessen angezeigt. Da steht z.B. statt "Rückstellungen" einfach nur "Rckstellungen". Und was an der Stelle völlig verrückt ist, ist die Tatsache, dass "ü" und "ö" nicht gehen, aber "ä" wird korrekt angezeigt... was soll das?

Die Anführungszeichen im Select-Statement waren bei den JDBC-Treibern auch nicht erfolgreich. Zum Teil war die Antwort dabei sogar "Syntaxfehler". Die Verbindung ist jeweils fehlerfrei, das Data-Dictionary wird im "Bearbeitungs-Modus" sogar angezeigt, nur ist weder eine Tabelle direkt zu browsen noch funktioniert irgendeine eine Abfrage.....

Irgendwie bin ich total verunsichert, weil das so "umfassend" nicht funktioniert... und ich bin da -was den grossen Konkurrenten- angeht, beruflicherseits ja total anderes gewohnt, weil da eigentlich immer alles klappt... aber genau den will ich ja jetzt eigentlich konsequent nicht mehr verwenden...

Ich hoffe, Ihr habt noch ein paar Ratschläge für mich...

vg, Maddin

[AndreasJBittner]

Hallo,

ich nutze überwiegend MySQL als RDBMS, da sind die Tabellennamen und Spalten als `Tabelle`.`Spalte`(beachte, das sind back ticks!) anzugeben, bei anderen können es Anführungszeichen "X" sein oder einfache Anführungszeichen 'X' und wieder anderen reicht Tabelle.Spalte, guck mal in die Doku oder probier mal rum.

Grüße
Andreas

[pmoegenb]

Hallo Maddin,

Du musst die Konfiguration des ODBC-Treibers unter System-DSN einrichten und als Systemdatenquelle SQLite3 Datasource benutzen, dann klappst auch mit den Umlauten.

Nach der Installation des ODBC-Treibers von hier http://www.ch-werner.de/sqliteodbc/ müsstest Du unter System-DSN als Name 3 Einträge wie folgt haben:

• SQLite Datasource
  SQLite UTF-8 Datasource
  SQLite3 Datasource

Weitere Informationen hier: http://de.openoffice.org/doc/howto/date ... ite_de.pdf

PS. Habe eben getestet, es geht auch über Benutzer-DSN.Wichtig ist halt, dass als ODBC-Treiber SQLite3 ODBC Driver definiert wird.

[MaddinR]

Hallo Leute

Danke für Eure Tips... ich habs hingekriegt...es klappt mit ODBC und mit SQLite. Warum nicht MySQL...?... ich hatte das an anderer Stelle hier im Forum vor einigen Tagen schon gesagt, ich möchte eigentlich keinen CPU-Overhead für eine gelegentlich genutzt DB, das heisst, keine ständig bereite und mitlaufende DB-Instanz, die ständig auf Connect's wartet. Mir reicht eine kleine DB, quasi sowas wie eine Desktop-DB, die als Back-End möglichst embedded/proprietär inside des Front-End läuft.

Was hat meine Probleme gelöst... ?... einige Maßnahmen:
1. Generieren einer neuen DB (File) mit SQLiteStudio (ohne Tabellen (!))
2. Generieren der Tabellen via SQL-Statements innerhalb OOo
3. Erneutes Importieren über den Umweg: kopieren internHSQL -> Exel -> OOoCalc -> OOoSQLiteTables

Der Weg Excel->OOoCalc mag irrsinig erscheinen... aber das war der einzige Weg, der bestimmte Datums-Formate beibehalten hat. Beispielsweise stand in einem Feld (Spalte) sowas wie "01. Jan.". Dieser Inhalt musste erhalten bleiben und durft nicht in was neues umgewandelt werden... wie z.B. eine Datumszahl, oder ein neues Datum mit "YYYY" dahinter. Ebenso klappte das über diese Umwege mit allen Umlauten....

Nun ja... es klappt jetzt... mit SQLite und Umlauten über ODBC... also mit Boardmitteln... ich hätte nur gerne auch mal die JDBC-Treiber probiert... aber das schlägt ständig fehl.

vg, Maddin

[pmoegenb]

Der Weg Excel->OOoCalc mag irrsinig erscheinen... aber das war der einzige Weg, der bestimmte Datums-Formate beibehalten hat. Beispielsweise stand in einem Feld (Spalte) sowas wie "01. Jan.". Dieser Inhalt musste erhalten bleiben und durft nicht in was neues umgewandelt werden... wie z.B. eine Datumszahl, oder ein neues Datum mit "YYYY" dahinter.

Hallo Maddin,

ich weiß nicht für was Du das benötigst, aber Dir ist schon bekannt, dass z. B. ein Seriendruckfeld entsprechend formatiert werden kann ?

Einfach Seriendruckfeld doppelt anklicken und als Format selbst definiert optieren.

[MaddinR]

ich weiß nicht für was Du das benötigst, aber Dir ist schon bekannt, dass z. B. ein Seriendruckfeld entsprechend formatiert werden kann ?
Einfach Seriendruckfeld doppelt anklicken und als Format selbst definiert optieren.

Hallo Peter

Ich muss jetzt gestehen, dass ich Deinen Hinweis nicht so ganz "einordnen" kann. An Seriendruck habe ich nämlich noch gar nicht gedacht. Und ich ich denke, wenn ich das mal brauche, dass ich dann vorher schon alle benötigten Felder "verzehrfertig" in der SQL-Abfrage zur Verfügung stellen würde, so das keine weitere Umformatierung notwendig wäre.

Bei meinem Problem handelte es sich um eine Datumsangabe, die kein Datumsfeld ist und die auch nicht in ein Datumsfeld umgewandelt werden darf. Das importierte Originaldatenformat ist "dd.MMM" und wird im weiteren für eine SQL-Plausibilitätsabfrage zu einem korrespondierendem echten Datumsfeld herangezogen. Wenn irgendein Prozess beim Importieren oder Kopieren dieses Feld manipulieren würde, würden danach die Plausis fehlschlagen. Möglicherweise lässt sich das über gewissen Aufwand wiederum auch anders lösen, aber bei Beibehaltung des originalen Feldinhaltes funktionieren die Plausis eben fehlerfrei. Und ich sehe keinen Grund dafür, dass irgendein Import-Prozess Originaldaten unerwünscht verändern darf.

Allerdings... was mich im Augenblick mehr beschäftigt.... ich würde ja zu gerne mal die JDBC-Treiber ans Rennen kriegen.... hat da keiner eine Idee?

vg, Maddin