PostgreSQL über ODBC

Werbung:
bei einer reinen PG-Lösung wäre dies ja kein Problem ...
Ist mir klar, ich rede von der MSSQL Developer.

Ich nutze das Projekt auch um ein bischen PG zu machen aber ich kann nicht komplett auf MS verzichten. Ich werde jetzt versuchen früh die Daten nach PG zu schreiben, dann alle Verarbeitungsschritte nach PG zu portieren und das Ergebnis später mit meinem MS Daten in der Produktiv-DB abgleichen.
 
Die Daten die dabei entstehen sollen mit produktiven Daten abgeglichen werden bzw. diese anreichern. Entwickeln ginge, aber nutzen müsste ich die Daten dann wieder auf einer Express DB. Außerdem verarbeite ich die Daten ja zum Zweck des produktiven Einsatzes, ich denke mal nach Lizenzbestimmungen ist das nicht gedeckt.

Verdienst du (oder der Kunde) mit der Lösung Geld? Dann sollte es ja kein Problem sein, dafür eine Lizenz zu kaufen.
 
Wenn es fertig ist spart mein Arbeitgeber damit hoffentlich Geld. Aber vermutlich nicht genug um davon Lizenzen zu kaufen, hab mal eben 7.200 Euro für Core und ca. 9.000 Euro für CAL based kalkuliert, das wäre dafür ein bischen oversized. Vermutlich kaufen wir irgendwann aus anderen Gründen eine entsprechende Lizenz.
 
Moin,

Ich bin neu hier und habe ein Problem das zum Titel dieses Threads passt.
Daher kann ich jetzt nicht helfen sondern suche selbst Hilfe. :)

Ich wollte jetzt dafür keinen neuen Thread auf machen.
Wenn das so nicht erwünscht ist möge jemand meine Frage bitte verschieben.

Ich bin dabei zwei unserer Anwendungen etwas zu modernisieren.
Plattform Windows.
Die beiden Programme A und B kommunizieren über eine alte PostgreSQL DB Version 9.3.
Beide Programme schreiben und lesen in der DB über das PSQL Plugin von Qt.
Da leider eine Portierung auf ein neueres Qt nicht möglich ist wird nur PG 9.x unterstützt.

Wir wollen aber den Kunden ermöglichen auf eine neuere DB zu migrieren.
Der Ansatz war nun den Zugriff über einen ODBC Treiber zu machen.
Im Prinzip eine gute Idee, aber jetzt hänge ich da etwas fest. :(

PostgreSQL 9.3
ODBC 9.3 und 12.2 getestet.

Das Problem:
Programm A schreibt in die DB und kann auch ohne Probleme lesen.
Die erzeugten Tabellen und Inhalte sehen korrekt aus.

Mit Zugriff direkt über PSQL kann B auch alles lesen und schreiben und funktioniert wie erwartet.
Wenn ich aber in B auch über ODBC arbeitet dann funktioniert gar nichts.
Ein Request wie SELECT .. FROM wird ohne Fehler ausgeführt und man merkt auch daß die DB etwas macht.
Aber das Ergebnis ist leer. :(

Der gleiche Request über pgAdmin ausgeführt liefert die erwarteten Daten.
Mit einem ODBC Query Tool geht es ebenfalls nicht.
Also das identische Verhalten wie bei meinem Programm B.

Ich dachte erst an ein Rechteproblem oder fehlendes Autocommit.
Aber das kann man wohl ausschließen.
Nun gehen mir langsam die Ideen aus was da sein kann.

Ich habe wenig Erfahrung mit ODBC und hoffe daß mir jemand mit mehr Ahnung da helfen kann.

Gruß
Micha
 
sorry, aber 9.3 ist 2013 erschienen und die etzte Version am 8.11.2018. Das ist komplett out of support. Es macht meiner Meinung nach wirklich NULL Sinn, da jetzt irgendwas fixen zu wollen, ihr solltet alles daran setzen, Eure komplett veraltete Landschaft zu erneuern.
 
sorry, aber 9.3 ist 2013 erschienen und die etzte Version am 8.11.2018. Das ist komplett out of support. Es macht meiner Meinung nach wirklich NULL Sinn, da jetzt irgendwas fixen zu wollen, ihr solltet alles daran setzen, Eure komplett veraltete Landschaft zu erneuern.
Wenn du richtig gelesen hättest, was du natürlich nicht hast, da wäre dir der Satz "Wir wollen aber den Kunden ermöglichen auf eine neuere DB zu migrieren." aufgefallen. Der Satz bedeutet Micha80 ist dran eine Migration für den Kunden zu machen. Aber dazu brauchst halt nun mal ein funkionierendes ODBC. Aber ok. Vielleicht kennst du dich auch nicht mit odbc und Postgresql 9.3 aus. Is ja alles drin.
 
Wir wollen aber den Kunden ermöglichen auf eine neuere DB zu migrieren.
Der Ansatz war nun den Zugriff über einen ODBC Treiber zu machen.
Im Prinzip eine gute Idee, aber jetzt hänge ich da etwas fest. :(

PostgreSQL 9.3
ODBC 9.3 und 12.2 getestet.

Das Problem:
Programm A schreibt in die DB und kann auch ohne Probleme lesen.
Die erzeugten Tabellen und Inhalte sehen korrekt aus.

Mit Zugriff direkt über PSQL kann B auch alles lesen und schreiben und funktioniert wie erwartet.
Wenn ich aber in B auch über ODBC arbeitet dann funktioniert gar nichts.
Ein Request wie SELECT .. FROM wird ohne Fehler ausgeführt und man merkt auch daß die DB etwas macht.
Aber das Ergebnis ist leer. :(

Der gleiche Request über pgAdmin ausgeführt liefert die erwarteten Daten.
Mit einem ODBC Query Tool geht es ebenfalls nicht.
Also das identische Verhalten wie bei meinem Programm B.

Ich dachte erst an ein Rechteproblem oder fehlendes Autocommit.
Aber das kann man wohl ausschließen.
Nun gehen mir langsam die Ideen aus was da sein kann.

Ich habe wenig Erfahrung mit ODBC und hoffe daß mir jemand mit mehr Ahnung da helfen kann.

Gruß
Micha
Hallo Micha, benutzen jetzt beide Programme ODBC oder nur Programm B? Nimmst Du als ODBC den psqlodbc? Evtl. mußt auch noch mal andere Versionen des ODBC Treibers ausprobieren und vielleicht helfen Dir die PostgreSQL ODBC FAQs.
 
Wenn du richtig gelesen hättest, was du natürlich nicht hast, da wäre dir der Satz "Wir wollen aber den Kunden ermöglichen auf eine neuere DB zu migrieren." aufgefallen. Der Satz bedeutet Micha80 ist dran eine Migration für den Kunden zu machen. Aber dazu brauchst halt nun mal ein funkionierendes ODBC. Aber ok. Vielleicht kennst du dich auch nicht mit odbc und Postgresql 9.3 aus. Is ja alles drin.
Wenn Du selber verstehen würdest, was Du schreibst ... Um von PG 9.3 auf eine aktuelle Version von PG zu migrieren braucht man kein ODBC.
 
Ich bin dabei zwei unserer Anwendungen etwas zu modernisieren.
Plattform Windows.
Die beiden Programme A und B kommunizieren über eine alte PostgreSQL DB Version 9.3.
Beide Programme schreiben und lesen in der DB über das PSQL Plugin von Qt.

Könnt ihr die 2 Programme soweit modifizieren, daß diese über die libpq auf PostgreSQL zugreifen? Ihr wollt sie ja eh modernisieren...
 
Hallo Micha, benutzen jetzt beide Programme ODBC oder nur Programm B? Nimmst Du als ODBC den psqlodbc? Evtl. mußt auch noch mal andere Versionen des ODBC Treibers ausprobieren und vielleicht helfen Dir die PostgreSQL ODBC FAQs.
Danke für die Hinweise.
Beide Programme laufen jetzt mit ODBC und ich benutze psqlodbc Version 12.
Damit kann ich auf eine PostgreSQL 12 und auch auf die Version 9 zugreifen.
Also vermutlich auch auf die Versionen dazwischen.

Wir wollen wie gesagt den Kunden ermöglichen eine neuere DB zu benutzen.
Aber wir können und wollen niemanden dazu zwingen.

Da die Versionen von PostgreSQL nicht kompatibel sind bräuchten wir bei direktem Zugriff jeweils verschiedene Versionen der beiden Anwendungen. Das geht vom Aufwand her gar nicht.
Deshalb der Ansatz mit ODBC. Da kann man die DB einfach wechseln ohne die Anwendung ändern zu müssen.

Ich habe das Problem inzwischen gefunden und gelöst. :)
Die Ursache war daß der ODBC-Treiber die Methode SqlQuery::size() nicht implementiert.
Das SELECT funktioniert also durchaus, aber das QSqlQuery::size() liefert immer -1 zurück.

Da vermutlich niemand die Größe des Ergebnisses abfragen möchte hat man das offenbar eingespart.
Das ist nur teuer und meistens auch unnötig.
Leider hat der frühere Entwickler diese Methode an diversen Stellen verwendet und deshalb hat es mit ODBC nicht funktioniert.
Ich habe das nun umgebaut und jetzt ist das Verhalten wie erwartet.
 
Noch eine ergänzende Frage:

Wir möchten natürlich eine möglichst neue Version der Datenbank unterstützen.
Leider ist das Projekt auf Windows 32 Bit limitiert.

Da habe ich als neueste Version eine PostgreSQL 12.11 gefunden.
Und das war schon recht mühsam.
Offiziell gibt es nur die Version 10.

Dazu benutze ich wie gesagt psqlodbc Version 12.
Da gibt es immerhin auch eine Version 13.2 aber nichts höheres.

Kennt jemand eine Quelle für beides in Version 13 oder gar 14?
Den möglichen Aufwand das selbst zu bauen kann ich vermutlich nicht verkaufen. :(
Wenn es denn überhaupt geht.
Ich kenne jetzt den Code nicht aber es dürfte schon einen Grund geben warum die neueren Versionen nicht in 32 Bit angeboten werden.
Auf dieser Plattform Tables mit bis zu 32 TB anzusprechen dürfte nicht ganz trivial sein.
Ich vermute das wurde gar nicht implementiert und daher lassen sich diese Versionen nicht bauen.
 
Wir wollen wie gesagt den Kunden ermöglichen eine neuere DB zu benutzen.
Aber wir können und wollen niemanden dazu zwingen.
Nennt sich Systemvoraussetzungen des Herstellers und ist ein gängiges Verfahren Gutes oder auch Schlechtes in der Welt zu tun. Ich finde es löblich wenn du/ihr Abwärtskompatibilität anbietet und das sollte man natürlich auch bis zu einem gewissen Punkt. Technisch wird das aber irgendwann nicht mehr tragbar und 32 Bit ist so ein Dämon wo man dann vielleicht mal klare Kante zeigen muss.
 
Werbung:
Technisch wird das aber irgendwann nicht mehr tragbar und 32 Bit ist so ein Dämon wo man dann vielleicht mal klare Kante zeigen muss.
Nun ja, im Prinzip richtig.
Aber in diesem Fall sind die Ansprüche an die DB doch sehr gering.
Niemand braucht da unbedingt 64 Bit und eine Tablesize von 32 TB. LOL
Das würde sich erst ändern wenn es auf der Plattform kein 32-Bit Subsystem mehr gäbe.
Aber das werde ich wohl nicht mehr erleben. :)

«Niemand braucht mehr als 640 Kilobyte Arbeitsspeicher in seinem PC.» (C) :)
 
Zurück
Oben