MS Access auf Linux ohne ODBC

[kimsey]

Hallo zusammen,

ich habe ein Problem der speziellen Art und konnte bisher noch keine Lösung finden:

Es soll auf einem Linux-System (kein ODBC verfügbar) auf einer Website aus einer MS-Access Datenbank (statisch als File vorhanden) gelsesen werden; vie Perl oder PHP, ganz egal.

Vielleicht hat ja einer von Euch eine Lösung parat? Bin erfreut über jeden sachdienlichen Hinweis ...

Thnx

[SeeksTheMoon]

wenn Du es mit Java machst, kannst Du JDBC verwenden, das mit Java mitgeliefert wird; es ist dann egal, ob es ODBC gibt oder nicht.

Wenn es unbedingt php oder perl sein muss, weiß ich auch nicht...

[kimsey]

Nunja, ich bräuchte dann aber trotzdem einen passenden Treiber für M$'s MDB Format. Aber Danke, ist vielleicht eine Möglichkeit ...

[elrond]

schau die das mal an, http://www.fastflow.it/dbftp/

vielleicht hilfts...

[kimsey]

Ein Proxy ist leider auch keine Lösung für das Problem, denn das würde voraussetzen, das ich noch eine zweite Maschine mit Windows zur Verfügung hätte.
An der Stelle hätte ich dann aber lieber JDBC:ODBC benutzt.

Trotzdem: Thnx.

[elrond]

hast du vielleicht die möglichkeit die "Datenbank" in ein lesbares format zu bringen. oder bedeutet "statisch" in deinem Fall etwas anderes als "wird nicht geändert" ?

[kimsey]

Naja, inzwischen konnte der Kunde überredet werden, das es der Realisierung zuträglicher ist, wenn er sich mit MySQL abfindet.

Die Idee dahinter war aber folgende: Den Inhalt dynamisch generierter Seiten kann durch den update, von auf dem Server liegenden Access Dateien, selber vornehmen. Jetzt bekommt er halt ein paar Eingabemasken dazu und fertig.

Überall wo ich gesucht habe habe ich keine Möglichkeit gefunden via Script, ohne ODBC auf einem Linux System auf eine .mdb zu zugreifen

Aber vielleicht findet ja wissender diesen Thread und hat die passende Lösung (ohne Krücken) parat.

Aber vielen Dank für die Anteilnahme und die guten Tipps.

Grüße,

Kimsey.

[elrond]

wenn der Kunde wirklich spass an Access hat bau ihm in Access einfach eine Export -Funktion entweder per odbc in eine MySql oder eben in Files. Etwas ähnliches praktizier ich mit MS-SQL-Server seit einer weile

[Christoph]

Bezüglich der Anforderungen deines Kunden kann ich nur spekulieren,
aber ich vermute mal, dass er Access Client Programme (d.h. mit VBA
zusammengestellte Makropakete) weiter benutzen möchte.

Nichts leichter als das: Access kann mit einer anderen Datenbank als
Backend betrieben werden, die dann einfach von Access per ODBC angesprochen
wird.

Allerdings würde ich Dir von MySQL abraten, da es zu viele wichtige
SQL2 Datenbankfeatures nicht implementiert hat (keine Views, keine Subqueries(!)
keine Foreign Keys(!!), kuriose Abweichung von den im SQL2-Standard festgelegten
Funktionen und Operatoren etc.); vermutlich werden die Client-Anwendungen mit
MySQL nicht mehr laufen.

Du solltest auf jeden Fall prüfen, ob Du mit PostgreSQl ggf. besser fährst.
Ein weiterer Vorteil von Postgres ist, dass mit Triggern und Stored Procedures
einiges von der Applikationslogik auf den Server verlagert werden kann.

Christoph

[jwebworks]

Naja, Du könntest ja

PostgreSQL verwenden, dass ist AnsiSQL kompatibel

cu, stop.h

[kimsey]

Du solltest auf jeden Fall prüfen, ob Du mit PostgreSQl ggf. besser fährst.

Ja, wenn's so schön einfach wär in der Welt. Leider möchte der Kunde, wie die meisten Kunden, natürlich kein Geld ausgeben, so das er mit anderen zusammen auf einem Server landet. Da muss er mit der default Config zufriden sein, und die ist eben MySQL.

die dann einfach von Access per ODBC angesprochen
wird.

Und genau das macht dem Admin angst - eine MySQL - auf der auch andere Kundendaten sind - offen im Netz.

Trotzdem Danke für den gutgemeinten Tipp. Aber ODBC ist IMHO ehrlichgesagt nur was fürs Intranet.

[elrond]

Ich würde, wie gesagt die Access Anwendung Daten in Files exportieren lassen.
Wenn der Export Textfiles mit insert-Statemants erzeugt kann das Einlesen klasse für die MYSQL automatisiert werden. Da der Kunde wahrscheinlich keine unternehmenskritischen Anwendungen ins INet verlegen will sondern "nur irgendwelche Daten rumgezeigt werden" könnte das ein sehr effektiver Weg sein gegen dean auch der Admin nichts haben sollte. Wenn dabei doch sehr vertrauliche daten durch die Gegend geschaufelt werden sollte der Kunde vielleicht doch eine etwas anspruchsvollere Variante wählen.

Ich betreibe eine MySQL im Internet die regelmässig mit Mails aktualisiert wird. Procmail gibt die Mails an die richtigen Perl-Scripts, die ihrerseits die DB füttern. Funxt seit über zwei Jahren ohne Probleme... Ist vielleicht auch ein Weg.

Ich hatte bisher übrigens nie einen Grund der MySQL zu mistrauen


Ist alles besser handlebar als sich via ODBC durch INet zu connecten. Ich kann dich da gut verstehen.