Anmelden

OpenSUSE 11.2

Die Softwareverwaltung erreicht man unter: Yast > Software > Online Update. Am besten nach ODBC suchen und folgende Pakete markieren.

  • psqlODBC
  • unixODBC

ODBC unter LINUX installieren (Ubuntu 9.1)

http://archives.postgresql.org/pgsql-odbc/2006-06/msg00104.php

http://www.easysoft.com/developer/interfaces/odbc/linux.html

https://help.ubuntu.com/community/ODBC

http://packages.ubunut.com/de/hardy/odbc-postgresql

Standardmäßig ODBC nicht installiert (Fehlermeldung libodbc.so). Folgende Pakete installieren (Ubuntu 9.1):

  • unixodbc ODBC tools libraries
  • unixodbc-bin Graphical tools
  • odbc-postgresql ODBC-Treiber PostgreSQL

Wenn man mit NET System.Data.Odbc.OdbcConnection arbeiten will muss man einen statischen Link auf die tatsächliche ODBC-Manager-Library setzen. In System.Data.Odbc.OdbcConnection wird nur  mit dem Dateinamen libodbc.so referenziert. Der Pfad der Library ist auf Linux-Systemen unterschiedlich mögliche Pfade sind z.B.:

/lib/usr/libodbc.so.1
/usr/lib/x86_64-linux-gnu/libodbc.so.1

Den aktuellen Pfad nach Installation von Unix-ODBC kann man per Suche ausfindig machen. Anschließen einen Link setzen mit ln:

find / -name libodbc.*
ln -s /lib/usr/libodbc.so.1 /lib/usr/libodbc.so

oder (bei Ubuntu 8.04 ist es andersrum):

ln -s /usr/lib/libodbc.so.1 /usr/lib/libodbc.so

Anschließend kann man den ODBC Administrator (ODBCConfig) starten. Dort muss man zuerst den Treiber hinzufügen, insbesondere Name, Description, Driver und Setup. Diese Daten werden in /etc/odbcinst.ini gespeichert.

[psqlodbc]
Description = PostgreSQL ODBC driver
Driver = /usr/lib/odbc/psqlodbca.so
Driver64 = /usr/lib
Setup = /usr/lib/odbc/libodbcpsqlS.so
Setup64 = /usr/lib
UsageCount = 1
CPTimeout =
CPReuse =

Anschließend richtet man im ODBC Administrator wie unter Windows den DSN ein. Allerdings gibt es hier keine Testmöglichkeit. Die DSN werden in /etc/odbc.ini gespeichert.

ODBC-Konfigurationsdateien PostGreSQL

/etc/odbcinst.ini

[psqlodbc]
Description  = PostgreSQL ODBC driver (unicode)
Driver  = /usr/lib/odbc/psqlodbca.so
Driver64  = /usr/lib
Setup  = /usr/lib/odbc/libodbcpsqlS.so
Setup64  = /usr/lib
UsageCount  = 1
CPTimeout  =
CPReuse  =

/etc/odbc.ini

[SMACC]
Description  = psqlodbc
Driver  = psqlodbc
Trace  = No
TraceFile  =
Database  = smacc
Servername  = 192.168.0.100
Username  = postgres
Password  = postgres
Port  = 5432
Protocol  = 6.4
ReadOnly  = No
RowVersioning  = No
ShowSystemTables  = No
ShowOidColumn  = No
FakeOidIndex  = No
ConnSettings  =

Besonderheiten NET (System.Data.Odbc)

Die Verwendung System.Data.Odbc mit den PostgreSQL-ODBC-Treibern unter LINUX ist möglicherweise mit verschiedenen Einstellungen verbunden. Generell haben wir uns entschieden mit UTF8-Datenbanken zu arbeiten.

Treiberversion und Umlaute

Es gibt zwei Treiber a und w (ebenso unter Windows). Vermutlich ist a=ANSI und w=UNICODE. Bei einer Unicode-Datenbank (UTF8) sollte vermutlich die w-Version verwendet werden. 

  • Allerdings hatte die w-Version nicht funktioniert, wenn man mit NET System.Data.Odbc.OdbcConnection arbeitet:           
    • ERROR [I000] [unixODBC]M
      at System.Data.Odbc.OdbcConnection.Open () [0x00000]
    • schneidet texte bei 127 Zeichen ab, es folgen ??????????

Dagegen funktioniert die a-Version psqlodbca normal auch mit UTF8-Datenbank. Vermutlich regelt NET dies selbst (hatte mal gehört, dass NET grundsätzlich mit UNICODE-Strings arbeitet). psqlodbca erfordert Einstellungen der Umgebungsvariablen LANG sonst gibt psqlodbca deutsche Umlaute als ?? wieder.

Das Problem hat nichts mit PostgreSQL oder UTF8-Datenbank zu tun, weil das selbe Verhalten auch mit MySQL-ODBC auftritt. Die Ursache liegt in der Überführung des UTF8-Streams und die NET-Unicode-Präsentation innerhalb System.Data.Odbc und kann durch die Umgebungsvariable LANG gelöst werden:

LANG=en_US.UTF-8

Es ist ferner zu überprüfen ob benötigte locales installiert ist und ggf. zu installieren (Debian und Ubunty):

locale -a
vi /etc/locale.gen

Folgend beiden locales sollten auskommentiert sein: de_DE.UTF-8 und en_US.UTF-8. Anschließend ausführen:

sudo locale-gen 

Beim Ausführen der ODBC-Zugriff mittels System.Data.Odbc sollte auch eine korrekte Einstellung LC_CTYPE vorliegen (kann man feststellen durch Aufruf von set). Falls die Umgebungsvariable nicht diesen Wert hat oder etwa UTF-8 fehlt, sollte man sie zuvor setzen:

LC_CTYPE=en_US.UTF-8

siehe auch:

Datumsfelder

  • System.Data.Odbc (Mono 2.4.4, Ubunty 8.08) kann keine Datumsfelder wiedergeben. Hier kommt eine Exception aus der System.Data.Odbc-Implementierung. Als Workarround konnten Datumfelder in dem SELECT-Statement in Textfelder konvertiert werden (siehe unten).

Prozeduren und Typen:

  • wenn man mit Prozeduren und Typen arbeitet, müssen in den Typen String-Felder eine ausreichende Länge tragen z.B. character (250). Bei Verwendung von (1) kommt es zu einem Fehler: System.Data.Common.StringDataContainer.SetValue. Das scheint zwar logisch, allerdings tritt das Problem nur in dieser Konstellation auf: unixODBC/ Mono

Datumsfelder

Unter bestimmen Umständen können Datumsfelder nicht direkt ausgegeben werden (dies ist momentan auf einem System Ubuntu 8.04 der Fall). Es wird ein Installationsproblem oder Besonderheiten in den Lokalisierungseinstellungen auf dem Server vermutet. Auf anderen Testsystemen (ubuntu 8.04 und 9.1) tritt dieser Fehler nicht auf:

System.ArgumentOutOfRangeException: Argument is out of range.
Parameter name: Parameters describe an unrepresentable DateTime.
at System.DateTime..ctor (Int32 year, Int32 month, Int32 day, Int32 hour, Int32 minute, Int32 second, Int32 millisecond)
[0x00000]
at System.DateTime..ctor (Int32 year, Int32 month, Int32 day, Int32 hour, Int32 minute, Int32 second) [0x00000]
at System.Data.Odbc.OdbcDataReader.GetValue (Int32 i) [0x00000]
at (wrapper remoting-invoke-with-check) System.Data.Odbc.OdbcDataReader:GetValue (int)
at System.Data.Odbc.OdbcDataReader.get_Item (Int32 i) [0x00000]
at Reportman.Reporting.ReportDataset.DoUpdateData () [0x00000]
at Reportman.Reporting.ReportDataset.set_CurrentReader (IDataReader value) [0x00000]
at Reportman.Reporting.DataInfo.Connect () [0x00000]
at Reportman.Reporting.BaseReport.ActivateDatasets () [0x00000]
error: at Reportman.Reporting.BaseReport.ActivateDatasets () [0x00000]

Ein Cast des Datums auf date (YYYY-MM-DD) nützt nichts.

Lösung

SQL-Ausdrücke in Report-Datensätzen der Report-Vorlage (.rep), die ein DateTime-Wert liefern müssen ersetzt werden, indem man datenbankseitig eine Umformatierung in Text vornimmt:

to_char(org_person.BirthDay,'DD.MM.YYYY') AS BirthDay,

oder

CASE WHEN pdatum IS NOT null
  THEN substring(cast(pdatum AS text),9,2)
  ||'.'||substring(cast(pdatum AS text),6,2)
  ||'.'||substring(cast(pdatum AS text),1,4)
ELSE null
END AS pdatum,

Links

Fehler nur bei 64 bit-Linux, kann offenbar nur durch Patch Mono OdbcDataReader.cs behoben werden

http://lists.ximian.com/pipermail/mono-devel-list/2007-May/023735.html

https://bugzilla.xamarin.com/show_bug.cgi?id=14443

   
Top

Wir arbeiten mit Software von http://www.campus21.de.

Verantwortlich für angezeigte Daten ist der Webdomain-Eigentümer laut Impressum.

Suche