www.peugeotforum.de

Morgen

Nachdem ich bei Google ned viel schlauer geworden bin frag ich mal hier, ob mit dieser Kombination jemand Erfahrungen hat.
Ziel ist es, von einem LAMP eine Access-Datenbank per ODBC zu öffnen, welche auf einem anderen (Windows-)Server liegt. php_odbc ist zu diesem Zweck selbstverständlich installiert.

Allerdings komme ich da irgendwie nicht weiter... Hab mal versucht das Script einfach auf den Linux-Rechner zu kopieren und beim Host die IP des Win-Rechners einzutragen. Ging nix. Nachm freischalten des Ports 9628 (Steuer-Port von ODBC) kam zumindest ein Connect zustande. Nen Datenaustausch hab ich aber noch ned geschafft, werd aber auch ned schlau, welche/r Port/s für den Datenaustausch mit der Access-Datenbank noch fällig wären...

Alternative wäre natürlich, lokal aufm Linux-Rechner einen ODBC-Server einzurichten... Hab da heute mitm installieren der Abhängigkeiten begonnen, aber das scheint wie immer eine unendliche Geschichte zu werden. Ich wär daher um jeden Tipp froh, der mir das erspart
Achso, ja, es muss ne Access-Datenbank sein. Die Entwickler unserer Warenwirtschaft konnten nix anderes als Access...

MfG Andreas

Was meinst Du mit Port freischalten?
Hängen die beiden Systeme nicht in der gleichen Zone?
Bzw sind da ein oder mehrere Router/Firewalls dazwischen?
Wie schauts mit der Windows-Firewall bzw der Iptables aus, könnten da eventuelle Regeln den Transfer auf anderen Ports blockieren?

Ich würde versuchen die beiden Systeme in den gleichen Netzkreis zu bekommen, alle Firewalls o.ä. deaktivieren und dann testen.

Wenns funktioniert, immer Schritt für Schritt an die Endkonfiguration herantasten und zwischendrin immer brav testen. Wenns dann auf einma net mehr geht, weisste warum

Ich persönlich kenn mich mit Access/ODBC nicht aus, allerdings trau ich Microsoft ne Menge zu, vor allem was dynamische Portzuweisung angeht..
Wie geschehen beim MSN Messenger, da soll man bei Problemen laut MS alle Ports von 1024-65535 in/out, TCP/UDP öffnen, man was haben wir in der Firma gelacht, wo wir das gelesen haben ^^

Hoffe geholfen zu haben

Die beiden hängen im gleichen Netz, allerdings fungiert der Windows-Rechner gleichzeitig als Gateway, drum möcht ich nicht unbedingt zu viele Ports aufmachn (=freischalten, womit wir die Frage mal hätten).

An Routern/Firewalls steht nur die Basisfirewall von Windows Server 2003 SP1 im Weg. Die beiden Rechner hängen ansonsten im selben Netz am selben Switch. IP-Konfig sieht wie folgt aus:
Win: 192.168.1.1/24, W2K3 SP1
Lin: 192.168.1.5/24, CentOS 5
Werd die Firewall ggf. morgen mal deaktiviern... Gibts halt 10 Minuten mal kein Internet.


Was die dynamische Portzuweisung angeht scheint ODBC ja eigentlich recht sparsam zu sein. Um bspw. extern über ODBC auf eine SQL-Datenbank zuzugreifen, sind die Ports 9628 und 3306 (Standard-SQL-Port) fällig. Habs zwar ned selbst versucht, so wars aber zahlreichen Dokumentationen zu entnehmen. Aber erzähl mir mal, auf welchem Port ich ne Access-Datenbank suchen muss... Nö, 139 bringt nix

Moin,

meine Access-Zeiten sind schon ein bisschen her, aber man brauchte damals keine Installation von Access. Man konnte die MDB überall hintragen. Packt die doch mal lokal, um erstmal was Funktionierendes zu haben.

@gr4vy: Das ist kein MS-typisches Problem. Java macht das genauso, unsere Netzwerker haben sich immer ein Loch in den Bauch gefreut, wenn wir Ports für Java freigeschaltet haben wollten

Gruß
Frank

mdbtools sollte helfen.
centos ist ein rh fork, da gibts das auch als rpm.

@Timon: Ist so weit richtig. Allerdings hilft die MDB allein nix, dazu gehört noch ein ODBC-Server.
Den hab ich jetzt mal in Form von unixODBC installiert. Dazu mdbtools und mdbtools-odbc.

Die dazugehörigen Configs sehen so aus:

/etc/odbc.ini hat geschrieben:[test]
Description = test-db
Driver = MDBToolsODBC
Database = /mnt/wawi/test.mdb
Servername = localhost
UserName =
Password =
port = 5432

/etc/odbcinst.ini hat geschrieben:[PostgreSQL]
Description = ODBC for PostgreSQL
Driver = /usr/lib/libodbcpsql.so
Setup = /usr/lib/libodbcpsqlS.so
FileUsage = 1

[MDBToolsODBC]
Description = MDB Tools ODBC drivers
Driver = /usr/lib/libmdbodbc.so.0
Setup =
FileUsage = 2
CPTimeout =
CPReuse =
UsageCount = 1

Verbindungsaufbau in PHP hat geschrieben:$datenbank = "test";
$odbc_user = "";
$odbc_pass = "";
$conn = odbc_connect($datenbank, $odbc_user, $odbc_pass);

Das Ergebnis daraus ist leider etwas ernüchternd...

Warning: odbc_connect() [function.odbc-connect]: SQL error: [unixODBC][Driver Manager]Can't open lib '/usr/lib/libmdbodbc.so.0' : /usr/lib/libmdbodbc.so.0: cannot enable executable stack as shared object requires: Permission denied, SQL state 01000 in SQLConnect in /var/www/html/include/datenbank.php on line 51

Die libmdbodbc.so.0 hat chmod 777, die gelinkte libmdbodbc.so.0.0.0 hatte 755. Letztere testweise auf 777 zu setzen brachte nix. Die Google-Suche zu dieser Fehlermeldung ist zwar umfangreich (kämpf grad noch mit den Ergebnissen), brachte mich bisher aber nicht weiter. Falls die obige Fehlermeldung also irgendjemandem was sagt, bitte vortreten...


Edit: Hab grad gelesen, dass mdbtools 0.5.1 nur Lesezugriff bietet. Wenn dem so ist, mache ich mich besser gleich nach anderen Lösungen auf die Suche. Schreibzugriff brauch ich bei diesem Projekt unbedingt.

Moin,

mh, gut, dann war der ODBC-Server in dem App-Server wohl "builtin"

Wäre das vielleicht eine Alternative?

http://www.aspheute.com/artikel/20010731.htm

Gruß
Frank

vulkanus hat geschrieben: Edit: Hab grad gelesen, dass mdbtools 0.5.1 nur Lesezugriff bietet. Wenn dem so ist, mache ich mich besser gleich nach anderen Lösungen auf die Suche. Schreibzugriff brauch ich bei diesem Projekt unbedingt.

Das ging aus Deinem Urposting nicht hervor.
Ohne ADO wird Schreibzugriff nichts, da kenne ich unter Linux/Unix nur kommerzielle Lösungen.
Hat lizenzrechtlichen Hintergrund, rate mal warum alle schon so lange auf mdbtools 0.6 warten..
;o)