nicht angemeldet
Hi!
Lieber dedlfix,
Dein automatischer Gruß spricht zwar mich an, aber ich kann dir hier nicht mit Erfahrung dienen, sondern nur meinen allgemeinen Senf zum Besten geben.
ich kann zwar die Funktion odbc_connect() aufrufen, aber ich kann nicht zur *.mdb-Datei verbinden. Zuerst kam die Fehlermeldung, dass kein Default-Treiber definiert sei, und dass die Quelldatei nicht gefunden würde.
ODBC ist seinerseits auch nur eine Abstraktion. Es ist gut möglich, dass die Linux-Lösung zweigeteilt ist - einmal allgemeine ODBC-Funktionalität und zum anderen ein DBMS-spezifischer Teil. Vielleicht erklären dir man-pages genauer, was die einzelnen DLLs so treiben (pun intended).
Mit (hoffentlich) passendem Editieren der Dateien odbc.ini und odbcinst.ini sieht das nun gottseidank besser(?) aus.
Mit den inis verhält es sich anscheinend wie unter Windows - in der odbc.ini stehen deine anwendungsspezifischen Angaben zur Datenquelle, in der odbcinst.ini stehen allgemeine Angaben zu den Treibern.
Aber irgendwie beschleicht mich das Gefühl, dass ich etwas falsch mache. Welche Bibliothek soll ich denn als Treiber angeben? Die Vielfalt der möglichen Dateien in /usr/lib ist verwirrend. Offensichtlich hat auch niemand je ein Interesse daran, zu dokumentieren, wie es bei ihm (oder ihr) je erfolgreich geklappt hat.
Anzunehmenderweise den DBMS-spezifischen Teil.
Jedenfalls habe ich in "/usr/lib/libodbc.so.1" einen dynamischen Link gefunden, den ich mit identischem Ergebnis nutzen kann, wie den ebenfalls dynamischen Link "/usr/lib/libmdb.so.1". In der nachfolgenden ini-Datei ist letzterer referenziert. Ich vermute mal, dass das Referenzieren von z.B. "/usr/lib/libmdb.so.1.0.0" nicht sinnvoll ist, falls die Bibliothek einmal durch eine aktualisiertere Version ersetzt werden soll. Stimmt das? Ist das der Grund für den dynamischen Link?
Ja, die dynamischen Links haben ja eine generischere Versionsnummer. Die eigentliche so-Datei kann ja aufgrund von Fehlerkorrekturen oder ähnlicher Weiterentwicklung erneuert werden und dann eine andere Nummer tragen. Die neue kann nun neben den früheren Versionen liegen, und so für "gestrige" Programme nutzbar bleiben. Verwender, die stattdessen nicht auf ältere Implementierungen angewiesen sind, bekommen über den Symlink die aktuelle Version.
---odbc.ini---
[nwind.mdb]
...Wenn ich nun zur Datenbank verbinden möchte, erhalte ich unter Verwendung des Codes
odbc_connect("DRIVER={Microsoft Access Driver (*.mdb)}; DBQ=nwind.mdb", "", "");
Unter Windows ist es nur üblich und ausreichend, den Parameter DSN (Data Source Name) anzugeben. Darüber werden alle anderen Angaben gefunden. Username und Password müssen nicht unbedingt zentral abgelegt werden, was ja sicherheitstechnisch nicht immer sinnvoll ist. Die können dann auch verbindungsindividuell mitgesendet werden. Der DSN dürfte in deinem Fall der Abschnittsname der odbc.ini (der in eckigen Klammern) sein.
den Fehler
"Warning: odbc_connect(): SQL error: [unixODBC][Driver Manager]Driver's
SQLAllocHandle on SQL_HANDLE_HENV failed,
SQL state IM004 in SQLConnect in /home/[...]/test.php on line 8".Für mich liest sich das, als ob der Treiber schon scheitert, bevor er an die DB "anklopft". Oder was ist hier falsch?
Probier es mal mit der alleinigen Angabe des DSN.
Zuerst hatte ich mich gefragt, wofür ich denn php5-odbc installieren sollte, wenn ich mdbtools nutzen möchte.
Das ist das Gegenstück in PHP, das nach unten ODBC spricht und nach oben PHPs odbc_*-Funktionen bereitstellt.
Aber anscheinend ist mit der Referenz auf libmdb.so.1 der mdbtools-Treiber tatsächlich in Gebrauch. Warum habe ich aber mit der Verwendung von libodbc.so.1 denselben Effekt? War mdbtools unnötig?
Wie schon gesagt, kann ich dich da nur auf man-pages und andere Dokumentation verweisen.
Lo!