Firebird mit LO-Base über ODBC - Integer-Eingaben unmöglich
Verfasst: So 21. Jul 2013, 09:47
Hallo *,
ich versuche seit einiger Zeit, die externe Datenbank "Firebird" mit LO-Base erfolgreich zu verbinden. Mit dem JDBC-Connector bekomme ich das halbwegs hin. Da muss lediglich beim Erstellen von Tabellen darauf geachtet werden, dass die Formatierung des Feldes mit dem Feldtyp übereinstimmt (macht z.B. grundsätzlich bei allen Zahlentypen einen Währungstyp - wenn das nicht direkt bei der Tabellenerstellung drauf geachtet wird, dann steht da nicht ID = 1, sonder ID = 1,00 €).
Probleme habe ich bei der Verbindung mit ODBC. Ich habe hier einen Linux-Rechner (OpenSUSE 12.3 64bit rpm). Ich bekomme die Verbindung auf der Konsole mit isql anstandslos hin, kann dort auch Daten eingeben und auslesen. Sobald ich aber mit Base über ODBC auf Firebird zugreife erscheinen zwei der vier Tabellen schreibgeschützt. Die nicht schreibgeschützten Tabellen sind komplett in Großbuchstaben geschrieben. Scheint in der Beziehung also schon einmal ein Problem der Quotierung mit " " zu sein. Gehe ich in die nicht schreibgeschützten Tabellen und versuche dort Eingaben zu tätigen, so werde ich jedes Mal rausgeschmissen mit der Warnung, dass der Primärschlüssel Null wäre (value "*** null ***").
Möchte ich eine Tabelle zum Bearbeiten öffnen oder eine neue Tabelle gründen, so stürzt LO gnadenlos ab.
Noch schlimmer ist es, wenn ich den Kontakt zu Base mit einer LO-Version 3.* versuche zu öffnen (oder auch der AOO 4 rc). Dann dreht sich die Eieruhr und nichts passiert. Ich kann die Prozesse schließlich nur noch killen.
Meine odbc.ini sieht inzwischen so aus:
Ich habe aus dem dem Treiber beiliegenden Vorschlag (Sourcecode → Linux) mit der Zeit alle Variablen entfernt. Mit isql läuft das Ganze weiter, mit Base leider auch keine Änderung.
Erste Ergänzung:
- diese Einstellungen zeigen alle Tabellen ohne Schreibschutz.
Das Einfügen ist mir bisher aber nur bei Primärschlüsseln des Typs VARCHAR gelungen. Andere Tabellen verweigern den Dienst mit der "*** null ***"- Warnung wie oben beschrieben.
Ich habe entsprechend den Betreff geändert.
Gruß
Robert
ich versuche seit einiger Zeit, die externe Datenbank "Firebird" mit LO-Base erfolgreich zu verbinden. Mit dem JDBC-Connector bekomme ich das halbwegs hin. Da muss lediglich beim Erstellen von Tabellen darauf geachtet werden, dass die Formatierung des Feldes mit dem Feldtyp übereinstimmt (macht z.B. grundsätzlich bei allen Zahlentypen einen Währungstyp - wenn das nicht direkt bei der Tabellenerstellung drauf geachtet wird, dann steht da nicht ID = 1, sonder ID = 1,00 €).
Probleme habe ich bei der Verbindung mit ODBC. Ich habe hier einen Linux-Rechner (OpenSUSE 12.3 64bit rpm). Ich bekomme die Verbindung auf der Konsole mit isql anstandslos hin, kann dort auch Daten eingeben und auslesen. Sobald ich aber mit Base über ODBC auf Firebird zugreife erscheinen zwei der vier Tabellen schreibgeschützt. Die nicht schreibgeschützten Tabellen sind komplett in Großbuchstaben geschrieben. Scheint in der Beziehung also schon einmal ein Problem der Quotierung mit " " zu sein. Gehe ich in die nicht schreibgeschützten Tabellen und versuche dort Eingaben zu tätigen, so werde ich jedes Mal rausgeschmissen mit der Warnung, dass der Primärschlüssel Null wäre (value "*** null ***").
Möchte ich eine Tabelle zum Bearbeiten öffnen oder eine neue Tabelle gründen, so stürzt LO gnadenlos ab.
Noch schlimmer ist es, wenn ich den Kontakt zu Base mit einer LO-Version 3.* versuche zu öffnen (oder auch der AOO 4 rc). Dann dreht sich die Eieruhr und nichts passiert. Ich kann die Prozesse schließlich nur noch killen.
Meine odbc.ini sieht inzwischen so aus:
Code: Alles auswählen
[Firebird-libretest]
Description = Firebird database libreoffice test
Driver = Firebird
Dbname = localhost:libretest.fdb
# Client =
# Role =
# CharacterSet = UTF-8
# ReadOnly = No
# NoWait = No
# Dialect = 3
# QuotedIdentifier = Yes
# SensitiveIdentifier = No
# AutoQuotedIdentifier = NoErste Ergänzung:
Code: Alles auswählen
SensitiveIdentifier = YesDas Einfügen ist mir bisher aber nur bei Primärschlüsseln des Typs VARCHAR gelungen. Andere Tabellen verweigern den Dienst mit der "*** null ***"- Warnung wie oben beschrieben.
Ich habe entsprechend den Betreff geändert.
Gruß
Robert