Anbindung Datenbank PostgreSQL oder Access

...sind aber nicht gleich groß und zeigen unterschiedliche ODBC-Treiber an. Mit einem der beiden Programme solltest Du den Postgres-Treiber sehen können, mit dem die Fremdsoftware in die Datenbank schreibt.

Anzeige

Hallo Zusammen,

ich versuche gerade mit LabView auf eine PostgreSQL Datenbank auf unserem Server zuzugreifen, jedoch bisher leider erfolglos.
Ich habe bisher auch keinerlei Erfahrung mit Datenbanken und SQL.
Ich habe den neuesten Postgre ODBC Treiber heruntergeladen und installiert.
Wenn ich unter System32 die odbcad32.exe ausführe ist da nichts von Postgre gelistet. Ich kann auf Hinzufügen klicken und sehe dann dort PostgreSQL ANSI(x64) und PostgreSQL Unicode(x64)
Wenn ich dann eins von beiden ausgewählt habe, komme ich auf ein Setup um den Treiber mit der Datenbank zu verknüpfen.
Da habe ich dann unter "Database" den Namen unserer Datenbank eingetragen und unter "Server" die IP-Adresse und Pfad unseres Servers eingetragen. Dazu noch Benutzername, Passwort und Port.
Wenn ich dann einen Test ausführe bekomme ich immer die Rückmeldung: "could not translate host name "\\192.168.1.251\..." to address: unknown host"
Ich habe auch schon versucht unter "Server" localhost einzutragen, aber dann kommt folgende Nachricht:
"could not connect to server: Connection refused (0x0000274D/10061) Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 5432?
could not connect to server: Connection refused (0x0000274D/10061) Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 5432?"
Laut unserer IT Abteilung akzeptiert der Server aber Verbindungen auf dem Port.

Hat jemand eine Idee, was ich noch probieren kann?! Ich stehe gerade etwas auf dem Schlauch.

Ich habe mit meinen bisherigen Bordmitteln versucht über das Database Connectivity Toolkit eine Verbindung aufzubauen.
Ich habe über "Werkzeuge -> Create Data Link" Microsoft OLE DB Provider for ODBC Drivers eine .udl Datei erstellt. Damit konnte ich auch erfolgreich eine Verbindung testen. Ich kann auch über die VIs eine Verbindung aufbauen. Wenn ich dann allerding z.B. eine Liste der verfügbaren Tabellen abfrage, bekomme ich nur ein leeres Array zurück, obwohl laut unserer IT mehrere Tabellen vorhanden sein müssen.
Deshalb dachte ich, es liegt evtl. an nicht korrekten Treibern und habe die oben beschriebenen Punkte ausprobiert.

Ich hoffe hier kann mir jemand weiter helfen.

Gruß
TDO

Bei LabVIEW 32-bit solltest du eine 32bit Variante des ODBC-Treibers installieren, und wenn du unter Windos 64bit arbeitest, dann musst du für die 32bit-Varianten dann die odbc32.exe unter SysWOW64 starten.

Gruß, Jens

EDIT: Ich arbeite lieber mit Conncectionsstrings anstatt UDL, und da kann ich die Seite https://www.connectionstrings.com/ empfehlen.

(16.11.2017 12:25 )jg schrieb:  Bei LabVIEW 32-bit solltest du eine 32bit Variante des ODBC-Treibers installieren, und wenn du unter Windos 64bit arbeitest, dann musst du für die 32bit-Varianten dann die odbc32.exe unter SysWOW64 starten.

Gruß, Jens

EDIT: Ich arbeite lieber mit Conncectionsstrings anstatt UDL, und da kann ich die Seite https://www.connectionstrings.com/ empfehlen.

Hallo Jens,

ich habe auch die 32-Bit Variante des Treibers installiert. Wenn ich dann unter SysWOW64 starte, kommen aber leider die gleichen Fehlermeldungen.
Ich habe dann jetzt die 32- und 64-Bit Variante der Treiber installiert. Kann das zu einem Problem führen?

Warum arbeitest du lieber mit Connectionstrings? Welchen Vorteil bringt das?

Gruß
TDO

(16.11.2017 12:48 )TDO schrieb:  Hallo Jens,

ich habe auch die 32-Bit Variante des Treibers installiert. Wenn ich dann unter SysWOW64 starte, kommen aber leider die gleichen Fehlermeldungen.
Ich habe dann jetzt die 32- und 64-Bit Variante der Treiber installiert. Kann das zu einem Problem führen?

Nach meiner Erfahrungen (allerdings mit MySQL und MS-SQL): nein.

(16.11.2017 12:48 )TDO schrieb:  Warum arbeitest du lieber mit Connectionstrings? Welchen Vorteil bringt das?

Reine Geschmackssache. Damit komm ich halt zu Recht, muss nicht einen extra File erzeugen, alles ist dann Teil vom Programmcode oder von Konfigurationsdateien.

Zwecks Fehlermeldungen: localhost schmeißt einen Fehler, da du höchstwahrscheinlich auf deinem Rechner keinen DB-Server laufen hast...
Und bei der Servereingabe würde ich mal ohne die Backslashes arbeiten, also nur 192.168.1.251

Gruß, Jens

EDIT: Schon den Anhang aus Beitrag 13 angeschaut? Der erzeugte UDL File ist auch nichts anderes als ein Connection-String.

Ich habe jetzt alle möglichen Varianten ausprobiert bei der Serverschreibweise, aber er schluckt es einfach nicht
Die Datenbank liegt ja unter der IP-Adresse in einem Unterordner usw. Sobald ich aber bei dem Server ein "\" einfüge z.B. 192.168.1.251\XYZ meckert er sofort und erkennt es nicht.
Wenn ich nur die IP Adresse angebe findet er da allerdings auch nichts.
Ich habe folgende Seite gefunden:
http://www.sparxsystems.com/enterprise_a...river.html

Da wird ja als Server auch nur ein Begriff eingegeben. Woher weiß das System dann wo der Server liegt? (Vermutlich liegt die Datenbank lokal, dann findet er sie?!) Muss ich mir den Pfad irgendwie als Netzlaufwerk oder so einbinden und den Namen des Netzlaufwerks angeben?! Ich komme leider echt nicht drauf.

Gruß
TDO

Anzeige

Ich verstehe nicht, wieso du einen Pfad auf die DB-Datei eingeben willst? Du verbindest dich mit dem Datenbank-Server-Dienst, nicht mit der Datei. Der weiß, welche Datenbanken es gibt und wo die Files liegen, das brauchst dich bei einer Verbindung per ODBC nicht zu interessieren. Allerhöchstens der Datenbankname - und selbst den braucht es nicht unbedingt, das kann man auch immer in die SQL-Kommandos einbauen.

Ich leg die nochmals die Connectionstrings ans Herz.

Gruß, Jens

Guten Morgen,

es hat sich jetzt zum Glück erledigt. Es gab wohl auf dem Server ein Problem, dass mir den Zugriff verweigert hat.
Unsere IT hat das gefixt und jetzt habe ich auch Zugriff darauf.
Die ConnectionStrings werde ich mir mal anschauen.
Danke

Gruß
TDO