6
Access mdb auf Server
Hallo liebe Leut,
ich habe zwar schon geoogelt, aber noch leider nichts aussagekräftiges gefunden. Bitte beantwortet mir doch folgendes Zenario:
Ich habe auf einem Terminal-Server eine mdb. Diese mdb greift per verknüpfte Tabellen auf einen anderen Oracle-Server zu.
So, nun möchte ich verschiedenen Leut hier im Neztwerk erlauben, diese Abfrage (in Form eines erstellten Formulars) zu starten. Ich dachte ich könne einen Link bereitstellen und die Access Runtime auf den Clients installieren.
Nun meldet sich aber der ODBC! Wie bekomme ich es hin, den Clients zugriff auf die Datei zu gewähren, ohne undbedingt ODBC einrichten zu müssen? Auf dem Terminal-Server ist ODBC richtig eingerichtet und funktioniert auch. Warum kann dieser Aufruf nicht vom Server aus geschehen?
Danke
Oder irgendwelche andere Lösungen?
ich habe zwar schon geoogelt, aber noch leider nichts aussagekräftiges gefunden. Bitte beantwortet mir doch folgendes Zenario:
Ich habe auf einem Terminal-Server eine mdb. Diese mdb greift per verknüpfte Tabellen auf einen anderen Oracle-Server zu.
So, nun möchte ich verschiedenen Leut hier im Neztwerk erlauben, diese Abfrage (in Form eines erstellten Formulars) zu starten. Ich dachte ich könne einen Link bereitstellen und die Access Runtime auf den Clients installieren.
Nun meldet sich aber der ODBC! Wie bekomme ich es hin, den Clients zugriff auf die Datei zu gewähren, ohne undbedingt ODBC einrichten zu müssen? Auf dem Terminal-Server ist ODBC richtig eingerichtet und funktioniert auch. Warum kann dieser Aufruf nicht vom Server aus geschehen?
Danke
Oder irgendwelche andere Lösungen?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 102522
Url: https://administrator.de/contentid/102522
Ausgedruckt am: 25.11.2024 um 14:11 Uhr
6 Kommentare
Neuester Kommentar
Die Clients müssen schon mit der verknüpften Oracle-Datenbank verbinden können, wenn die mdb dort laufen soll. Dafür musst Du auf jedem Client sowieso die Oracle-Treiber installieren.
Du könntest ODBC recht schnell z.B. per Registry-Datei einrichten:
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI auf einem eingerichteten Rechner exportieren und überall verteilen. Die Treiber etc. müssen dann aber im gleichen Verzeichnis liegen, sonst muss entsprechend angepasst werden.
Wenn Du den Aufwand treiben willst eine eigene ADM-Datei zu erstellen, kannst Du die Registryeinträge auch per Gruppenrichtlinie verteilen.
Wenn Du entsprechend programmieren kannst, könntest Du die Tabelleneinbindung bei installierten Treibern auch zur Laufzeit bewerkstelligen.
Diese Lösungen lohnen aber aus meiner Sicht nur bei wechselnden Servern/Verbindungen. Das Aufrufen einer Registry-Datei bei der Einrichtung der Treiber reicht in der Regel aus.
Du könntest ODBC recht schnell z.B. per Registry-Datei einrichten:
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI auf einem eingerichteten Rechner exportieren und überall verteilen. Die Treiber etc. müssen dann aber im gleichen Verzeichnis liegen, sonst muss entsprechend angepasst werden.
Wenn Du den Aufwand treiben willst eine eigene ADM-Datei zu erstellen, kannst Du die Registryeinträge auch per Gruppenrichtlinie verteilen.
Wenn Du entsprechend programmieren kannst, könntest Du die Tabelleneinbindung bei installierten Treibern auch zur Laufzeit bewerkstelligen.
Diese Lösungen lohnen aber aus meiner Sicht nur bei wechselnden Servern/Verbindungen. Das Aufrufen einer Registry-Datei bei der Einrichtung der Treiber reicht in der Regel aus.
Danke für die schnelle Antwort. Nun ja, dies wollte ich eigentlich umgehen, auf den jeweiligen Clients die Oracle-Treiber zu installieren. Zudem werden dann die Benutzer immer das Passwort eingeben müssen?! Und das sollen sie eigentich nicht wissen.
Danke
Danke
Moin starter,
ergänzend und bestätigend zu NilsEriks Kommentar:
Ja, es hilft nix: bei ein einer Nur-2-Tier-Architektur müssen nun mal auch alle Clients die ODBC-Treiber ALLER Datenbanken installiert haben, mit denen sie sich irgendwie unterhalten.
Wobei es böse Zungen gibt, die M$Access bestenfalls als eine 1-Tier-Applikation bezeichnen würden.
Zu prüfender Workaround bzw. Kompromissvorschlag:
Falls die Clients die gesammelten Daten nicht gerade realtime/Sekundenaktuell benötigen, sondern auch jeweils mit dem Stand vom Vortag (oder einer Synchronisation alle 6 Stunden oder so) leben könnten, dann...
Wenn aber tatsächlich via Clients auch in allen beteiligten Tabellen geändert werden soll (Oracle und Access), dann brauchen die Clients eben die beiden ODBC-Treiber bzw ärgerlicherweise eine Oracle-Client-installation.
Grüße
Biber
ergänzend und bestätigend zu NilsEriks Kommentar:
Ja, es hilft nix: bei ein einer Nur-2-Tier-Architektur müssen nun mal auch alle Clients die ODBC-Treiber ALLER Datenbanken installiert haben, mit denen sie sich irgendwie unterhalten.
Wobei es böse Zungen gibt, die M$Access bestenfalls als eine 1-Tier-Applikation bezeichnen würden.
Zu prüfender Workaround bzw. Kompromissvorschlag:
Falls die Clients die gesammelten Daten nicht gerade realtime/Sekundenaktuell benötigen, sondern auch jeweils mit dem Stand vom Vortag (oder einer Synchronisation alle 6 Stunden oder so) leben könnten, dann...
- könntest Du die Unterhaltung mit den Oracle-Instanzen einer Stored Procedure (also PL/SQL auf Oracle oder eben eine Stored Procedure M$-seitig/MSSqlServer) führen lassen. Okay, auf dem Server müssen natürlich alle ODBC-Treiber installiert sein.
- diese Stored Procedure kann dann die Tabellen in einer der DBs bereitstellen, also z.B. in einer Access-MDB.
- wobei wir den Faden aber nur weiterspinnen sollten, wenn die Clients diese Daten auch nur lesend bearbeiten sollen.
Wenn aber tatsächlich via Clients auch in allen beteiligten Tabellen geändert werden soll (Oracle und Access), dann brauchen die Clients eben die beiden ODBC-Treiber bzw ärgerlicherweise eine Oracle-Client-installation.
Grüße
Biber
Auch nicht schlecht...
Die Clients sollen nur lesend darauf zugreifen können. Von dem her ..... Aber es sind doch einige Datensätze und dann parallel nochmal eine Datenbank fahren ... ich weiß nicht.
Nun gut, dann ist die Oracle-Installation wohl doch die bessere Lösung, zumindest recourcen sparender.
Wei kann ich dann das Passwort für die Oracle-Datenbank hinterlegen? Ich möchte nicht, dass die User dieses kennen.
Grüße
starter
Die Clients sollen nur lesend darauf zugreifen können. Von dem her ..... Aber es sind doch einige Datensätze und dann parallel nochmal eine Datenbank fahren ... ich weiß nicht.
Nun gut, dann ist die Oracle-Installation wohl doch die bessere Lösung, zumindest recourcen sparender.
Wei kann ich dann das Passwort für die Oracle-Datenbank hinterlegen? Ich möchte nicht, dass die User dieses kennen.
Grüße
starter
Hallo,
beim Einbinden der Oracle-Tabellen in ACCESS kann das Passwort fest hinterlegt werden, einfach den vorhandenen Haken setzen. (auch möglich wenn die Tabelle mit VBA eingebunden wird)
Gruß - René
beim Einbinden der Oracle-Tabellen in ACCESS kann das Passwort fest hinterlegt werden, einfach den vorhandenen Haken setzen. (auch möglich wenn die Tabelle mit VBA eingebunden wird)
Gruß - René
super, vielen dank, habe es hin bekommen
