Hallo,
ich habe hier folgendes aus 4 Teilen bestehendes Szenario:
1. Datenbank Server (Centura SQLBase [NT]) - kann ODBC 2. eigentliche Datenbankstruktur (export per SQL möglich) - enthält Stammdaten, die mit (3.) bearbeitet werden - enthält sog. Erfahrungsdaten, die mit (4.) bearbeitet werden 3. Windows Anwendung (Centura SQL Windows) - kann auf ODBC Quellen zugreifen und arbeitet mit (2.)
4. "Web-"anwendung (unimplementiert - in Entwurfsphase)
Mit der Win32 Anwendung soll weiterhin gearbeitet werden können. Nun kann sich der geneigte Leser sicherlich vorstellen, daß ich auf keinen Fall (4.) auf Win32 laufen/entwickeln möchte.
Ich kann (1.) austauschen, wenn ich Anpassungen der SQL Statements in (3.) vornehme, was nicht sonderlich schwer sein sollte. Allerdings um den Preis, daß ich in begrenztem Umfang dann für die Pflege von (3.) verantwortlich sein werde.
Die Tests ob ich PostgreSQL nutzen kann laufen gerade. Mit Postgres ist ein ODBC Treiber für Win32 frei zu bekommen, sodaß man eigentlich alles hat, was man braucht - nur ist noch nicht sicher, wie gut das funktioniert (aber das ist nicht die Frage).
Offen bleibt die andere Lösung, wo man (1.) beibehält und versucht, darauf von Linux über ODBC zuzugreifen. Hat jemand sowas schon mal gemacht? Mit welchem Erfolg?
Tschau,
andre
On Sat, May 25, 2002 at 02:33:08PM +0200, Andre Schulze wrote:
Offen bleibt die andere Lösung, wo man (1.) beibehält und versucht, darauf von Linux über ODBC zuzugreifen. Hat jemand sowas schon mal gemacht? Mit welchem Erfolg?
Hier auf meinem Debian (woody):
$ apt-cache search odbc
gda-odbc - GDA backend server for ODBC godbcconfig - GTK Based ODBC Configuration GUI libadaodbc1 - Runtime library for the GNat Ada Database Environment -> libdbd-odbc-perl - Perl5 module for an ODBC driver for DBI libiodbc2 - iODBC Driver Manager libiodbc2-dev - iODBC Driver Manager (development files) libmyodbc - MySQL ODBC driver libphp-adodb - The 'adodb' database abstraction layer for php. libqt3-mt-odbc - ODBC plugin for Qt3 (Threaded) libqt3-odbc - ODBC plugin for Qt3 libsqlxx-dev - C++ classes for database access via ODBC libsqlxx2.2 - C++ classes for database access via ODBC odbc-postgresql - ODBC support for PostgreSQL odbcinst1 - Support library and helper program for accessing odbc ini files php4-odbc - ODBC module for php4 pike7.2-odbc - Odbc module for Pike tora - A graphical toolkit for database developers and administrators. unixodbc - ODBC tools libraries unixodbc-bin - Qt-based GUI ODBC tools unixodbc-dev - ODBC libraries for UNIX (development files)
Wobei ich das markierte für den besten Weg halte, wenn ich Dein Problem richtig verstanden haben sollte.
Als Perl-Modul über CPAN heißt das Teil sicher DBD::ODBC.
Heiko
Am Sun den 26 May 2002 um 11:32:09AM +0200 schrieb lug-dd-admin@schlittermann.de:
On Sat, May 25, 2002 at 02:33:08PM +0200, Andre Schulze wrote:
Offen bleibt die andere Lösung, wo man (1.) beibehält und versucht, darauf von Linux über ODBC zuzugreifen. Hat jemand sowas schon mal gemacht? Mit welchem Erfolg?
Hier auf meinem Debian (woody):
$ apt-cache search odbc-> libdbd-odbc-perl - Perl5 module for an ODBC driver for DBI odbcinst1 - Support library and helper program for accessing odbc ini files unixodbc - ODBC tools libraries
Wobei ich das markierte für den besten Weg halte, wenn ich Dein Problem richtig verstanden haben sollte.
Nachdem ich noch mal bei unixODBC mich etwas schlauer gemacht habe [1], sieht es wohl so aus, als ob man immer einen für das verwendete Datenbank- system einen Treiber benötigt. Mein System (Centura SQLBase) ist nicht unterstützt :-(
andre
Am Montag, 27. Mai 2002 14:08 schrieb Andre:
Nachdem ich noch mal bei unixODBC mich etwas schlauer gemacht habe [1], sieht es wohl so aus, als ob man immer einen für das verwendete Datenbank- system einen Treiber benötigt. Mein System (Centura SQLBase) ist nicht unterstützt :-(
Jetzt bin ich irritiert. Du schriebst in deiner ersten Mail, dass deine Datenbank ODBC kann.
ODBC steht für "Open Database Connectivity*. Diese Schnittstelle wurde doch extra erschaffen um einen Standard zur Anbindung einer exotischen Datenbank an $Lieblingsprogrammiersprache zu bieten. Über diese Schnittstelle werden die SQL-Anfragen zur DB geleitet und die Antworten sollten zurück kommen. Vermutlich wird man nicht alle Funktionen zur Administration nutzen können, aber das war anscheinend auch nicht die Aufgabe.
<Bitte korrigieren, wenn falsch> Die Datenbank muss eine ODBC-Schnittstelle haben (Problem des Herstellers eine zu programmieren) => Jede ODBC-fähige Software sollte nach dem Anpassen der SQL-Befehle (Ja, ja es ist eine Standard ;-) mit der Datenbank kommunizieren können.
Jens Weiße
Am Mon den 27 May 2002 um 06:00:32PM +0200 schrieb Jens Weie:
Am Montag, 27. Mai 2002 14:08 schrieb Andre:
Nachdem ich noch mal bei unixODBC mich etwas schlauer gemacht habe [1], sieht es wohl so aus, als ob man immer einen für das verwendete Datenbank- system einen Treiber benötigt. Mein System (Centura SQLBase) ist nicht unterstützt :-(
Jetzt bin ich irritiert. Du schriebst in deiner ersten Mail, dass deine Datenbank ODBC kann.
So richtig habe ich ODBC noch nicht verstanden, wie es scheint. Es ist in den ganzen Schemata die ich bisher gefunden habe nicht immer ganz klar, was Teil des Servers und des Clients ist. ODBC fähig heißt im Fall des DBMS (1.), daß es einen ODBC Treiber gibt, der auf der Seite des Client arbeitet.
ODBC steht für "Open Database Connectivity*. Diese Schnittstelle wurde doch extra erschaffen um einen Standard zur Anbindung einer exotischen Datenbank an $Lieblingsprogrammiersprache zu bieten. Über diese Schnittstelle werden die SQL-Anfragen zur DB geleitet und die Antworten sollten zurück kommen. Vermutlich wird man nicht alle Funktionen zur Administration nutzen können, aber das war anscheinend auch nicht die Aufgabe.
<Bitte korrigieren, wenn falsch> Die Datenbank muss eine ODBC-Schnittstelle haben (Problem des Herstellers eine zu programmieren) => Jede ODBC-fähige Software sollte nach dem Anpassen der SQL-Befehle (Ja, ja es ist eine Standard ;-) mit der Datenbank kommunizieren können.
Anwendung -> Treibermanager -> Datenbanktreiber -> DBMS (ODBC Datenqullen- in Windows)
Leider habe ich das noch nicht klarer gefunden. Was hier fehlt ist wie erwähnt die Grenze, wo das Netzwerk den Client vom Server trennt. So wie ich es im Moment verstehe liegt die zwischen Datenbanktreiber und DBMS. Kann hier jemand Licht ins Dunkel bringen?
Tschau,
andre
Andre Schulze wrote:
ODBC fähig heißt im Fall des DBMS (1.), daß es einen ODBC Treiber gibt, der auf der Seite des Client arbeitet.
Ja so sieht das wohl überall aus. Der mysql-odbc-Treiber wird auch auf dem (Windows-)Client installiert, damit u.a. Access per DSN drauf zugreifen kann.
Die ODBC-Befehle von PHP sagen nichts über eine IP-Adresse oder eine anderweitige Bezeichnung des DB-Hosts aus:
odbc_connect(string DSN, string user, string password[, int cursor_option])
Leider habe ich das noch nicht klarer gefunden. Was hier fehlt ist wie erwähnt die Grenze, wo das Netzwerk den Client vom Server trennt.
ODBC selbst ist scheinbar nicht netzwerkfähig.
So wie ich es im Moment verstehe liegt die zwischen Datenbanktreiber und DBMS. Kann hier jemand Licht ins Dunkel bringen?
Da sich der Treiber um's Netzwerk kümmert ist das wohl so.
Damit brauchst Du entweder einen ODBC-Treiber für Linux oder du nimmst ein DBMS mit Windows-ODBC-Treiber.
Dein Windows-Support sollte dann am Treiber bzw. einrichten der DSN enden. Wenn die den gleichen Namen hat solltest Du nicht am Programm rumschrauben müssen.
Offen bleibt, welche Funktionalität der ODBC-Treiber hat und wie diese von dem Client genutzt werden.
Rico
Am Mon den 03 Jun 2002 um 04:57:12PM +0200 schrieb Rico Koerner:
Andre Schulze wrote:
[...noch mal ne Antwort für's Mailinglistenarchiv]
ODBC fähig heißt im Fall des DBMS (1.), daß es einen ODBC Treiber gibt, der auf der Seite des Client arbeitet.
Ja so sieht das wohl überall aus. Der mysql-odbc-Treiber wird auch auf dem (Windows-)Client installiert, damit u.a. Access per DSN drauf zugreifen kann.
Ja, das geht auch mit PostgreSQL ganz gut, leider reicht es aber nicht, damit die "legacy" Windows Anwendung (3) damit arbeiten kann. Die hat noch mal ne Schicht dazwischen. Soll heißen, man muß diesem System erst noch die Datenbanken bekannt machen, obwohl die schon vom ODBC Treibermanager verwaltet sind. Krank, krank, krank das.
Die ODBC-Befehle von PHP sagen nichts über eine IP-Adresse oder eine anderweitige Bezeichnung des DB-Hosts aus:
odbc_connect(string DSN, string user, string password[, int cursor_option])
Leider habe ich das noch nicht klarer gefunden. Was hier fehlt ist wie erwähnt die Grenze, wo das Netzwerk den Client vom Server trennt.
ODBC selbst ist scheinbar nicht netzwerkfähig.
Jein, der Treiber mappt die ODBC Schnittstelle auf die native Schnittstelle des DBMS. Da die nativen Treiber idR netzwerkfähig sind, ist ein ODBC Treiber das dann auch - mehr oder weniger aber "nur" implizit.
So wie ich es im Moment verstehe liegt die zwischen Datenbanktreiber und DBMS. Kann hier jemand Licht ins Dunkel bringen?
Da sich der Treiber um's Netzwerk kümmert ist das wohl so.
Ja, aber es ist nicht näher definiert, daß es so sein muß.
Damit brauchst Du entweder einen ODBC-Treiber für Linux oder du nimmst ein DBMS mit Windows-ODBC-Treiber.
Letzters geht theoretisch, scheitert aber an den o.g. Details... .
Dein Windows-Support sollte dann am Treiber bzw. einrichten der DSN enden. Wenn die den gleichen Namen hat solltest Du nicht am Programm rumschrauben müssen.
Offen bleibt, welche Funktionalität der ODBC-Treiber hat und wie diese von dem Client genutzt werden.
Wir werden jetzt wohl mit Java arbeiten. Der JDBC Treiber funktioniert nach ersten Tests. JDBC ist wohl ODBC modulo Treibermanager rein in Java implementiert. Somit ist das portabel. Nach einer Session mit einem Java Freak habe ich dann 3.5 Stunden später eingesehen, daß wir damit wohl unsere Lösung gefunden haben. Das liegt aber weniger an JDBC, als an den Möglichkeiten, die uns die Platform Java bietet (Abstratkion der Datenbank Schicht auf eine Objekt- schicht, die dann obendrüber eine GUI bzw. Web -repräsentationssicht haben kann/wird)
Schauen wir mal,
andre
lug-dd@mailman.schlittermann.de
-
Andre Schulze -
Andre Schulze -
Jens Weiße -
None -
Rico Koerner