3
Access Linked Tables - ODBC Verbindung fehlgeschlagen
Probleme bei ODBC Verbindung zwischen Access und Oracle
Hallo,
ich arbeite an einem Projekt mit Access und Oracle Backend. Access besitzt Linked Tables die über ODBC auf einen Oracle Server (10g) verknüpft sind. Ziel der ganzen Anwendung ist die Generierung von Reports über Daten die in der Oracle Datenbank gehalten werden. Die Generierung eines solchen Reports kann (dank Access) bis zu 8 Stunden dauern.
Gerade aber bei komplexen Reports kommt es inzwischen eigentlich regelmäßig vor dass nach ca. 2 Stunden Access den Vorgang mit der Meldung "ODBC Verbindung fehlgeschlagen" abbricht. Kann es sein dass die ODBC Verbindung einfach gekappt wird und Access nun versucht dies inaktive Verbindung zu nutzen und deswegen abschmiert? Und falls ja, wie kann man das verhindern?
Danke schonmal im Voraus
Jens
Hallo,
ich arbeite an einem Projekt mit Access und Oracle Backend. Access besitzt Linked Tables die über ODBC auf einen Oracle Server (10g) verknüpft sind. Ziel der ganzen Anwendung ist die Generierung von Reports über Daten die in der Oracle Datenbank gehalten werden. Die Generierung eines solchen Reports kann (dank Access) bis zu 8 Stunden dauern.
Gerade aber bei komplexen Reports kommt es inzwischen eigentlich regelmäßig vor dass nach ca. 2 Stunden Access den Vorgang mit der Meldung "ODBC Verbindung fehlgeschlagen" abbricht. Kann es sein dass die ODBC Verbindung einfach gekappt wird und Access nun versucht dies inaktive Verbindung zu nutzen und deswegen abschmiert? Und falls ja, wie kann man das verhindern?
Danke schonmal im Voraus
Jens
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 46886
Url: https://administrator.de/forum/access-linked-tables-odbc-verbindung-fehlgeschlagen-46886.html
Ausgedruckt am: 01.05.2025 um 23:05 Uhr
3 Kommentare
Neuester Kommentar
Moin jay187,
zu der eigentlichen Frage, wie ein Client eine 4-Stunden-Connection zu Server halten kann, wenn keinerlei erkennbare Kommunikationsaktivitäten zwischen Client und Server in diesem Zeitraum laufen...
..dazu kann ich nichts sagen, aber ich würde auch eher lachend in die Kreissäge springen, als das Problem von dieser Seite anzugehen.
Wenn komplexe und zeitaufwändige Reports auf dem Oracle-Server laufen sollen, dann kann das eben auch eine kleine PL/SQL-Stored Procedure auf dem Server abfackeln lassen..
... alles andere istBullshit suboptimal.
Gerade für Reports und Auswertungen sind doch drei Eigenschaften typisch:
1. Um Konsistenz in allen gelesenen Datenbeständen zu gewährleisten, darf ohnehin für die Dauer des Auswertunglaufs kein anderer User ändern, hinzufügen oder löschen.
2. Da dieses ein eher unbefriedigender Datenbank-Zustand für alle anderen Clients ist, sollte er so kurz wie möglich gehalten werden == so schnell laufen wie möglich == dort laufen, wo der Weg zu den Daten am kürzesten ist==auf dem Server.
3. Komplexere Auswertungen auf einer Access-Gurke würden erfordern, dass Riesen-Rohdatenmengen/Resultsets über die Leitung geschaufelt werden, um danach auf dem Client!! kreuz und quer durchgeharkt und verdichtet zu werden.
Da würde Dich jeder DB-Admin-Azubi im zweiten Ausbildungsmonat mit einem nassen Handtuch erschlagen bei dem Konzept.
Also schreddert schnell eine kleine PL/SQL - STP zusammen - wenn ihr keine Erfahrung damit habt, kann ich gerne dabei unterstützen.
Weiterer ungefragter Tipp: Wenn ihr heute schon derartige Reports habt, solltet ihr eher über ein "echtes" Auswertungs/Reportingtool nachdenken.
Neben den vorhandenden Oracle-Aufsattel-Lösungen (einziger Nachteil: erhöht natürlich die Festlegung auf einen bestimmten, wenn auch sehr guten DB-Anbieter) gibt s auch sehr gute Lösungen für in beliebiger Form vorliegenden Input-Dateien aus verschiedenen Datenbanken ode Datenquellen.
Dazu würde sich mal ein Blick auf "BusinessObjects/ BOXI R2" lohnen, mit dem Du von Deinen Clients aus individuelle Auswertungen auf definierte Daten-"Universen" anstossen kannst.
Wäre meine Empfehlung - aber es gehen natürlich auch andere universelle BI-Produkte.
Auch dazu stehe ich gerne zu Detailfragen zur Verfügung.
Grüße
Biber
zu der eigentlichen Frage, wie ein Client eine 4-Stunden-Connection zu Server halten kann, wenn keinerlei erkennbare Kommunikationsaktivitäten zwischen Client und Server in diesem Zeitraum laufen...
..dazu kann ich nichts sagen, aber ich würde auch eher lachend in die Kreissäge springen, als das Problem von dieser Seite anzugehen.
Wenn komplexe und zeitaufwändige Reports auf dem Oracle-Server laufen sollen, dann kann das eben auch eine kleine PL/SQL-Stored Procedure auf dem Server abfackeln lassen..
... alles andere ist
Gerade für Reports und Auswertungen sind doch drei Eigenschaften typisch:
1. Um Konsistenz in allen gelesenen Datenbeständen zu gewährleisten, darf ohnehin für die Dauer des Auswertunglaufs kein anderer User ändern, hinzufügen oder löschen.
2. Da dieses ein eher unbefriedigender Datenbank-Zustand für alle anderen Clients ist, sollte er so kurz wie möglich gehalten werden == so schnell laufen wie möglich == dort laufen, wo der Weg zu den Daten am kürzesten ist==auf dem Server.
3. Komplexere Auswertungen auf einer Access-Gurke würden erfordern, dass Riesen-Rohdatenmengen/Resultsets über die Leitung geschaufelt werden, um danach auf dem Client!! kreuz und quer durchgeharkt und verdichtet zu werden.
Da würde Dich jeder DB-Admin-Azubi im zweiten Ausbildungsmonat mit einem nassen Handtuch erschlagen bei dem Konzept.
Also schreddert schnell eine kleine PL/SQL - STP zusammen - wenn ihr keine Erfahrung damit habt, kann ich gerne dabei unterstützen.
Weiterer ungefragter Tipp: Wenn ihr heute schon derartige Reports habt, solltet ihr eher über ein "echtes" Auswertungs/Reportingtool nachdenken.
Neben den vorhandenden Oracle-Aufsattel-Lösungen (einziger Nachteil: erhöht natürlich die Festlegung auf einen bestimmten, wenn auch sehr guten DB-Anbieter) gibt s auch sehr gute Lösungen für in beliebiger Form vorliegenden Input-Dateien aus verschiedenen Datenbanken ode Datenquellen.
Dazu würde sich mal ein Blick auf "BusinessObjects/ BOXI R2" lohnen, mit dem Du von Deinen Clients aus individuelle Auswertungen auf definierte Daten-"Universen" anstossen kannst.
Wäre meine Empfehlung - aber es gehen natürlich auch andere universelle BI-Produkte.
Auch dazu stehe ich gerne zu Detailfragen zur Verfügung.
Grüße
Biber
Hallo Biber,
erst einmal Danke für Deine Antwort. Und zu meiner Verteidigung: das ganze Konszept stammt nicht von mir. Es ist ein laufendes System bei einem Kunden. Bisher lief die ganze Geschichte noch auf MySQL. Nur da macht jetzt langsam die DB schlapp. Der Kunde ist auch schon dabei ein neues System zu integrieren. Nur da kommt der Lieferant nicht hinterher. Und da komme ich ins Spiel. Bis das neue System steht wird die laufende Applikation auf Oracle umgestellt, da Oracle mit 160.000.000 Datensätzen bestimmt besser zurecht als MySQL.
Inzwischen haben wir auch schon eine Lösungsmöglichkeit gefunden. Unter Access kann man einzelnen Abfragen auch noch explizit einen ODBC-Timeout-Wert mitgeben. Der ist standardmäßig auf 60secs. Haben den jetzt mal erhöht und siehe da, beim nächsten Auswertungslauf lief die Geschichte jetzt weiter und hing aber dann bei der nächsten komplexeren Anfrage. Naja mal sehen wie es aussieht wenn es bei allen geändert wurde.
Im diesen Sinne, abwarten und Tee trinken.
Gruß
jay187
erst einmal Danke für Deine Antwort. Und zu meiner Verteidigung: das ganze Konszept stammt nicht von mir. Es ist ein laufendes System bei einem Kunden. Bisher lief die ganze Geschichte noch auf MySQL. Nur da macht jetzt langsam die DB schlapp. Der Kunde ist auch schon dabei ein neues System zu integrieren. Nur da kommt der Lieferant nicht hinterher. Und da komme ich ins Spiel. Bis das neue System steht wird die laufende Applikation auf Oracle umgestellt, da Oracle mit 160.000.000 Datensätzen bestimmt besser zurecht als MySQL.
Inzwischen haben wir auch schon eine Lösungsmöglichkeit gefunden. Unter Access kann man einzelnen Abfragen auch noch explizit einen ODBC-Timeout-Wert mitgeben. Der ist standardmäßig auf 60secs. Haben den jetzt mal erhöht und siehe da, beim nächsten Auswertungslauf lief die Geschichte jetzt weiter und hing aber dann bei der nächsten komplexeren Anfrage. Naja mal sehen wie es aussieht wenn es bei allen geändert wurde.
Im diesen Sinne, abwarten und Tee trinken.
Gruß
jay187
Sagen wir so, jay187,
da Dein Problem nun offensichtlich gelöst ist, habe ich auch keinerlei Problem damit, diesen Beitrag entsprechend mit einem grünen Haken zu versehen und zu schließen.
Sollte allerdings in meinem Umfeld jemals irgendjemand den DB-Timeout für Client-Connections auf 10000 setzen wollen, wird er/sie sicherlich eine ähnliche Ansprache zu hören bekommen.
Ich sehe jedenfalls keinen Grund, an irgendeiner Stelle von meinen Aussagen oben abzugehen.
Grüße
Biber
da Dein Problem nun offensichtlich gelöst ist, habe ich auch keinerlei Problem damit, diesen Beitrag entsprechend mit einem grünen Haken zu versehen und zu schließen.
Sollte allerdings in meinem Umfeld jemals irgendjemand den DB-Timeout für Client-Connections auf 10000 setzen wollen, wird er/sie sicherlich eine ähnliche Ansprache zu hören bekommen.
Ich sehe jedenfalls keinen Grund, an irgendeiner Stelle von meinen Aussagen oben abzugehen.
Grüße
Biber
