Über das Netzwerk auf Sybase DB zugreifen
Mit PHP auf Sybase 10 Datenbank verbinden
Hallo zusammen,
ich versuche schon seit längerem mich mit einer Sysbase System 10 DB zu verbinden.
Die DB ist im Netzwerk auf einem Server über einen bestimmten Port (beispielsweise
Port 1000 ) ansprechbar.
Nun versuche ich von einem Windows XP Rechner im Netzwerk, auf dem ein
Apache Web Server läuft eine verbindung herzustellen.
Ich habe auf dem Client keine Treiber installiert, auf dem Server sind ODBC treiber vorhanden
Habe versucht über System -> verwaltung -> Datenquellen (ODBC) ein
System DNS zu setzen.
Leider kann ich hier keien Port angeben oder Ähnliches-
Vielleicht ist es hier jemanden ein leichtes mir einige Tipps zu geben.
Viele Grüße
SOA
Hallo zusammen,
ich versuche schon seit längerem mich mit einer Sysbase System 10 DB zu verbinden.
Die DB ist im Netzwerk auf einem Server über einen bestimmten Port (beispielsweise
Port 1000 ) ansprechbar.
Nun versuche ich von einem Windows XP Rechner im Netzwerk, auf dem ein
Apache Web Server läuft eine verbindung herzustellen.
Ich habe auf dem Client keine Treiber installiert, auf dem Server sind ODBC treiber vorhanden
Habe versucht über System -> verwaltung -> Datenquellen (ODBC) ein
System DNS zu setzen.
Leider kann ich hier keien Port angeben oder Ähnliches-
Vielleicht ist es hier jemanden ein leichtes mir einige Tipps zu geben.
Viele Grüße
SOA
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 83602
Url: https://administrator.de/contentid/83602
Ausgedruckt am: 23.11.2024 um 00:11 Uhr
10 Kommentare
Neuester Kommentar
Moin soa,
ich gebe zu, ich bin technologisch eventuell nicht mehr so ganz auf dem Laufenden.
Damals, als ich noch mit Datenbanken herumgealbert habe, war zum ODBC-Zugriff schon ein auf dem Client installierter Treiber (auf neudeutsch: eine DLL) nötig, um mehr mit einer Datenbank zu veranstalten als nach der Systemzeit zu fragen.
Hier habe ich ein Onlinebocck aus diesen guten alten Zeit ausgegraben: Sybase System 10 ODBC Reference Guide.
Funktionieren sollte dieser Weg auch heute noch...
Grüße
Biber
ich gebe zu, ich bin technologisch eventuell nicht mehr so ganz auf dem Laufenden.
Damals, als ich noch mit Datenbanken herumgealbert habe, war zum ODBC-Zugriff schon ein auf dem Client installierter Treiber (auf neudeutsch: eine DLL) nötig, um mehr mit einer Datenbank zu veranstalten als nach der Systemzeit zu fragen.
Hier habe ich ein Onlinebocck aus diesen guten alten Zeit ausgegraben: Sybase System 10 ODBC Reference Guide.
Funktionieren sollte dieser Weg auch heute noch...
Grüße
Biber
Moin soa,
freut mich natürlich, dass Du es zum Fliegen gebracht hast.
Dennoch hat die Java-Variante (also über eine API und über über .RegisterDriver()) nur entfernt etwas mit dem Einrichteten einer Benutzer- oder System-DSN zu tun.
Eine DSN kannst Du nicht ohne installierte und registrierte ODBC-Clienttreiber einrichten, daher meine Verwunderung.
Aber what shalls.... - Problem ist gelöst.
Frohe Ostern.
Biber
freut mich natürlich, dass Du es zum Fliegen gebracht hast.
Dennoch hat die Java-Variante (also über eine API und über über .RegisterDriver()) nur entfernt etwas mit dem Einrichteten einer Benutzer- oder System-DSN zu tun.
Eine DSN kannst Du nicht ohne installierte und registrierte ODBC-Clienttreiber einrichten, daher meine Verwunderung.
Aber what shalls.... - Problem ist gelöst.
Frohe Ostern.
Biber
Moin soa,
dann ein kurzer Versuch der Gegenüberstellung ohne Gewähr und ohne Anspruch auf Vollständigkeit.
ODBC und JDBC haben zwar die gleichen Wurzeln und den gleichen Grundgedanken (physikalisch unterschiedliche DBRMS-Implementierungen über eine einheitliche Schnittstelle abzufackeln), aber es gibt auch tendenzielle Unterschiede.
ODBC-Treiber
JDBC-Treiber
JDBC/ODBC-Bridge
Soweit stehend freihändig runtergetippt - es gibt sicher auch "Richtiges" im Netz.
Falls Du da was Nettes findest, setze einfach den Link darunter.
Grüße
Biber
dann ein kurzer Versuch der Gegenüberstellung ohne Gewähr und ohne Anspruch auf Vollständigkeit.
ODBC und JDBC haben zwar die gleichen Wurzeln und den gleichen Grundgedanken (physikalisch unterschiedliche DBRMS-Implementierungen über eine einheitliche Schnittstelle abzufackeln), aber es gibt auch tendenzielle Unterschiede.
ODBC-Treiber
- M$'s Weg. Und auch der ältere.
- Dazu werden DB-spezifische Treiber(-bibliotheken), fast immer vom DB-Hersteller höchstselbst bereitgestellt.
- Das sind meist in C geschriebene DLLs, die installiert+registriert werden müssen und vergleichsweise tief ins Innenleben des Betriebssystems eingreifen
- Deshalb unter neueren Windowsversionen immer hohe/Administratorrechte nötig
- sind betriebssystem/M$-Versionsabhängig, auf eine spezielle DB-Version bezogen
- und es gibt es immer vom DB-Hersteller und/oder stabil und/oder rechtzeitig. Meist ist nur einer der drei Punkte gegeben.
- Philosopie: Die DB-Hersteller selbst wissen ja am Besten, was wohl der kleinste gemeinsame Nenner aller 127000 Datenbankservervarianten sein wird. Dann sollen die halt sicherstellen, dass sich einer Applikation mit ODBC-Verbindung zu einem Datentopf als physikalische Datenbank ein Excel, eine Oracle-Instanz oder ein PostGreSQL unterjubeln lässt. Die Appz redet immer nur in der gleichen Sprache mit einer DSN und mit dem gleichen "Standard"-SQL.
- Darau resultierender Nachteil: ein ODBC-Treiber ist der kleinste gemeinsame Nenner von dem, was Datenbankserver können. Kann sein, dass die DB ganz tolle Features/Erweiterungen hat, die kaufentscheidend waren. Über ODBC kannst Du die nicht nutzen - der Treiber versteht es nicht.
JDBC-Treiber
- Sun's Antwort auf ODBC.
- komplett in Java implementiert - nix DLL, nix installation, nix muss der Admin einrichten
- wird "nebenbei" mit dem Applet (wenn es webbasiert ist) oder mit der Java-Appz auf dem Client deployed. Wenn Du z.B. den DBVisualizer oder eine andere SQL-Client-Workbench einrichtest, hast du "die Datenbanktreiber" mit dabei - ohne Setup und ohne Install.
- Plattform/OS/Versionsunabhängig
- Philosophie: eine Open-Source-Entwicklung ist ja vielleicht genauso flexibel und stabil und up to date... und er wird häufiger mal aktualisiert. Und die Beschränkung auf "kleinsten gemeinsamen Nenner" ist eher freiwillig.
- Nachteil: der Entwickler/Anwender muss diesen kryptischen Connection-String (siehe Dein jTDS-Beispiel) eintippen können,
JDBC/ODBC-Bridge
- Mischvariante. Wenn ohnehin (schon) ein ODBC-Treiber installiert ist oder als gegeben hingenommen wird, dann kann ich den natürlich auch nutzen, wenn ich ein Java-Programm bin. Dann gehe ich halt quasi über eine JDBC-API, die als Gesprächspartner eine (ODBC-)DLL-API hat. Why not. Besser, als alles neu zu erfinden.
Soweit stehend freihändig runtergetippt - es gibt sicher auch "Richtiges" im Netz.
Falls Du da was Nettes findest, setze einfach den Link darunter.
Grüße
Biber