4
Access ueber ODBC an SQL-Server: Timeout bei einer einzelnen Abfrage
Crosspost nach Windows > Office > Access und Internet & Intranet > Datenbanken, da Access und SQL-Server das Problem sein können.
Hallo zusammen,
wir haben hier ein Problem in der Zusammenarbeit zwischen MS-SQL Server und MS-Access.
Die Accessanwendung greift über ODBC auf Tabellen und Views auf MS-SQL zu. Aus den Server-Tabellen und -views werden für spezielle Reports über verschiedene Abfragen neue Tabellen zusammengerechnet. Normalerweise funktionieren die so erstellten Reports problemlos. Wenn jedoch die verwendeten Datensamples grö�er werden, bricht Access die Bearbeitung ab mit folgender Fehlermeldung:
ODBC-Aufruf fehlgeschlagen [Mirosoft][ODBC SQL ServerDriver] timeout abgelaufen (# 0)
Ich interpretiere dies so, das in der Kommunikation zwischen Server und Arbeitsstation die vorgegebene Wartezeit eines der beiden Beteiligten Rechner überschritten wurde. Lt. Hilfe zu der Fehlermeldung soll dieser Fehler bei Netzwerkproblemen auftreten. Dies kann jedoch ausgeschlossen werden, da das Netzwerk ansonsten problemlos funktioniert und auch keine besonders hohe Netzlast aufweist.
Nun meine Frage: Kennt jemand einen Weg, das beschriebene Problem zu vermeiden. Gibt es z.B. Möglichkeiten das, der Fehlermeldung zugrunde liegende Timeout des ODBC-Treibers hochzusetzen und wenn ja, wie.
Bin für jede Anregung offen und dankbar
geTuemII
Hallo zusammen,
wir haben hier ein Problem in der Zusammenarbeit zwischen MS-SQL Server und MS-Access.
Die Accessanwendung greift über ODBC auf Tabellen und Views auf MS-SQL zu. Aus den Server-Tabellen und -views werden für spezielle Reports über verschiedene Abfragen neue Tabellen zusammengerechnet. Normalerweise funktionieren die so erstellten Reports problemlos. Wenn jedoch die verwendeten Datensamples grö�er werden, bricht Access die Bearbeitung ab mit folgender Fehlermeldung:
ODBC-Aufruf fehlgeschlagen [Mirosoft][ODBC SQL ServerDriver] timeout abgelaufen (# 0)
Ich interpretiere dies so, das in der Kommunikation zwischen Server und Arbeitsstation die vorgegebene Wartezeit eines der beiden Beteiligten Rechner überschritten wurde. Lt. Hilfe zu der Fehlermeldung soll dieser Fehler bei Netzwerkproblemen auftreten. Dies kann jedoch ausgeschlossen werden, da das Netzwerk ansonsten problemlos funktioniert und auch keine besonders hohe Netzlast aufweist.
Nun meine Frage: Kennt jemand einen Weg, das beschriebene Problem zu vermeiden. Gibt es z.B. Möglichkeiten das, der Fehlermeldung zugrunde liegende Timeout des ODBC-Treibers hochzusetzen und wenn ja, wie.
Bin für jede Anregung offen und dankbar
geTuemII
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: 24602
Url: https://administrator.de/contentid/24602
Ausgedruckt am: 24.11.2024 um 22:11 Uhr
4 Kommentare
Neuester Kommentar
Moin Silke,
Hmm, da hab ich keine richtig guten Nachrichten für Dich - ein TimeOut-Problem bei einer SQL-Datenbank ist immer grundsätzlich Serverseitig. Und meistens auch global gültig (also für entweder die gesamte DB oder ähnliche Dimensionen). Das heißt, Du kannst sie weder für einzelne Connections hochsetzen und schon gar nicht für einzelne User, Prozessuser oder Applikationen/Clients.
Wenn das alles wurscht ist, also der TimeOut auch global für alle anderen Daten(banken), die auf dem Server liegen, hochgesetzt werden kann, dann siehe im MS SQL-Server-Handbuch.
(Ich glaube mich dunkel zu erinnern, irgendwo unter Eigenschaften, Erweiterte Einstellungen oder so ähnlich..zu lange her, sorry)
Falls noch ein Gateway dazwischen ist, hat auch der ein paar Stellschrauben, aber ein Gateway ist ja bei einer Access-M$SQLServer-Konstellation eher unwahrscheinlich.
Wenn also wirklich TimeOuts auftreten, ist allerdings auch die erste Überprüfung, ob die DB nicht zu recht abwinkt und einen Vogel zeigt - vielleicht sind die Abfragen ja nicht einfach nur "komplex", sondern zusätzlich auch ungeschickt/inperformant formuliert.
Und würden auch bei einem dreimal zu hohen TimeOut-Wert in die Grütze gehen, weil ein kartesisches Produkt gebildet wird oder keine verwendbaren Indizes gefunden werden und jedesmal ein kompletter TableScan gemacht wird... Zeit für Analyse/Explain-Tools.
Aber auch das alles serverseitig.
Und der eigentlich richtige Schritt ist IMHO die Verlagerung der Last weg von den Clients und weg von dem massiven Datentransport von Client zu Server und retour.
Verwendet Stored Procedures, Trigger oder im Extremfall de-normalisierte Datenmodelle und (ja, redundante) Aggregatstabellen serverseitig.
(Für unverbindliche Datenmodell-Betrachtungen und/oder SQL-Script-Optimierungen hast Du ja meine PN)
Und sollte irgendein Fachmann kommen und Dir einen Weg zeigen, wie Du den TimeOut-Wert verdreifachen kannst - das hilft von heute bis März dieses Jahres. Vergiss diese Lösung.
Grüße Biber
Hmm, da hab ich keine richtig guten Nachrichten für Dich - ein TimeOut-Problem bei einer SQL-Datenbank ist immer grundsätzlich Serverseitig. Und meistens auch global gültig (also für entweder die gesamte DB oder ähnliche Dimensionen). Das heißt, Du kannst sie weder für einzelne Connections hochsetzen und schon gar nicht für einzelne User, Prozessuser oder Applikationen/Clients.
Wenn das alles wurscht ist, also der TimeOut auch global für alle anderen Daten(banken), die auf dem Server liegen, hochgesetzt werden kann, dann siehe im MS SQL-Server-Handbuch.
(Ich glaube mich dunkel zu erinnern, irgendwo unter Eigenschaften, Erweiterte Einstellungen oder so ähnlich..zu lange her, sorry)
Falls noch ein Gateway dazwischen ist, hat auch der ein paar Stellschrauben, aber ein Gateway ist ja bei einer Access-M$SQLServer-Konstellation eher unwahrscheinlich.
Wenn also wirklich TimeOuts auftreten, ist allerdings auch die erste Überprüfung, ob die DB nicht zu recht abwinkt und einen Vogel zeigt - vielleicht sind die Abfragen ja nicht einfach nur "komplex", sondern zusätzlich auch ungeschickt/inperformant formuliert.
Und würden auch bei einem dreimal zu hohen TimeOut-Wert in die Grütze gehen, weil ein kartesisches Produkt gebildet wird oder keine verwendbaren Indizes gefunden werden und jedesmal ein kompletter TableScan gemacht wird... Zeit für Analyse/Explain-Tools.
Aber auch das alles serverseitig.
Und der eigentlich richtige Schritt ist IMHO die Verlagerung der Last weg von den Clients und weg von dem massiven Datentransport von Client zu Server und retour.
Verwendet Stored Procedures, Trigger oder im Extremfall de-normalisierte Datenmodelle und (ja, redundante) Aggregatstabellen serverseitig.
(Für unverbindliche Datenmodell-Betrachtungen und/oder SQL-Script-Optimierungen hast Du ja meine PN)
Und sollte irgendein Fachmann kommen und Dir einen Weg zeigen, wie Du den TimeOut-Wert verdreifachen kannst - das hilft von heute bis März dieses Jahres. Vergiss diese Lösung.
Grüße Biber
Hallo Biber,
ich habe den Abfrage-Timeout in den Datenbankeigenschften mal testhalber verdoppelt, das tut. Damit die User Ruhe geben, lasse ich das mal temporär so, aber da müssen wir sicher nochmal ran.
Wie grundsätzliche DBstruktur können wir nicht beeinflussen, da wir eine DB abfragen, die zu einer Fremdsoftware gehört (keine Panik --> reine Auswertung). Mal sehen, was sich machen läßt...
Eine Frage habe ich aber noch: Der Abfrage-Timeout steht ja standardmäßig bei 600 sec. Die Abfrage brauch jetzt, da sie durchläuft, bis zum Aufbau der Printvorschau ca 70 sec. Irgendwie passen mir diese beiden Zahlen nicht so wirklich zusammen oder sehe ich da den Wald wiedermal vor Bäumen nicht?
Ich danke Dir jedenfalls schon mal für Dein Angebot, ich werde mich bemühen, Dich zu verschonen
Schönen Abend noch, geTuemII
ich habe den Abfrage-Timeout in den Datenbankeigenschften mal testhalber verdoppelt, das tut. Damit die User Ruhe geben, lasse ich das mal temporär so, aber da müssen wir sicher nochmal ran.
Wie grundsätzliche DBstruktur können wir nicht beeinflussen, da wir eine DB abfragen, die zu einer Fremdsoftware gehört (keine Panik --> reine Auswertung). Mal sehen, was sich machen läßt...
Eine Frage habe ich aber noch: Der Abfrage-Timeout steht ja standardmäßig bei 600 sec. Die Abfrage brauch jetzt, da sie durchläuft, bis zum Aufbau der Printvorschau ca 70 sec. Irgendwie passen mir diese beiden Zahlen nicht so wirklich zusammen oder sehe ich da den Wald wiedermal vor Bäumen nicht?
Ich danke Dir jedenfalls schon mal für Dein Angebot, ich werde mich bemühen, Dich zu verschonen
Schönen Abend noch, geTuemII
Na, das ging ja flott, Silke... *anerkennend Augenbraue heb*
Und Eure Clients gehen dann eben auf diese superglatte, superschnellen Daten. Merkt keiner und alle sind glücklich (okay, die Daten sind natürlich ein klein wenig asynchron, aber wenn es um "Auswertungen" geht, dann ist es dem Benutzer doch egal, wenn seine angezeigten Daten den Stand eines DB-Laufs vom heutigen Morgen um 05h haben.
Der vermisst die Daten von heute mittag wohl kaum.
Dann lass da aber jemand ran, der sich mit so was (Datenmodellen) auskennt. Muss kein Biber sein, sollte aber auch nicht ein Azubi oder Euer Haus-und-Hof-VB-Programmierer sein.
Liegt Euch wenigstens das Datenmodell dieser Fremdsoftware dokumentiert und offen vor?
Oder sieht ihr da mit Trial-and-Error und Orientierung aufgrund der Feldnamen draufgegangen?
Bei WIEVIEL???? Das sind 10 Minuten?!?!?!? In 10 Minuten ist doch schon lange die Connection weg.. das kommt mir SEHR SEHR hoch vor.
Inwieweit die beiden Werte (Server-Timeout und "gemessene Zeit" vom Senden der Client-Abfrage bis zum abgeschlossenen Bildschirmaufbau) bei M$ miteinander korrespondieren... keine Ahnung. M$ hat mir auch schon mal angezeigt: "Kopiervorgang zu 644% abgeschlossen..." und danach hat es noch zwei Tassen Kaffee gedauert.
Seh ich schon so gebrechlich aus, dass ich Schonung brauche? Schonkaffee?
Oh..Schongleichfeierabend...
Schönen Abend
Biber
Die grundsätzliche DBstruktur können wir nicht beeinflussen, da wir eine DB abfragen, die zu einer Fremdsoftware gehört (keine Panik --> reine Auswertung).
Na ja..da sehe ich keinen Widerspruch. Ihr könnt auch mit serverseitigen Stored Procedures auf diese Fremd-Zukauf-Tabellen... diese "vorbereiten"/filtern/Bereinigen/konsolideren.Und Eure Clients gehen dann eben auf diese superglatte, superschnellen Daten. Merkt keiner und alle sind glücklich (okay, die Daten sind natürlich ein klein wenig asynchron, aber wenn es um "Auswertungen" geht, dann ist es dem Benutzer doch egal, wenn seine angezeigten Daten den Stand eines DB-Laufs vom heutigen Morgen um 05h haben.
Der vermisst die Daten von heute mittag wohl kaum.
Mal sehen, was sich machen läßt...
Liegt Euch wenigstens das Datenmodell dieser Fremdsoftware dokumentiert und offen vor?
Oder sieht ihr da mit Trial-and-Error und Orientierung aufgrund der Feldnamen draufgegangen?
Eine Frage habe ich aber noch:
Der Abfrage-Timeout steht ja standardmäßig bei 600 sec.
Der Abfrage-Timeout steht ja standardmäßig bei 600 sec.
Inwieweit die beiden Werte (Server-Timeout und "gemessene Zeit" vom Senden der Client-Abfrage bis zum abgeschlossenen Bildschirmaufbau) bei M$ miteinander korrespondieren... keine Ahnung. M$ hat mir auch schon mal angezeigt: "Kopiervorgang zu 644% abgeschlossen..." und danach hat es noch zwei Tassen Kaffee gedauert.
ich werde mich bemühen, Dich zu verschonen...
Oh..Schongleichfeierabend...
Schönen Abend
Biber
Problem ist zunächst gelöst, erfordert aber noch einige Nacharbeit, ich vermelde eventuelle Erfolge
Im Crosspost habe ich einen entsprechenden Hinweis gesetzt.
Grüsse, geTuemII
Im Crosspost habe ich einen entsprechenden Hinweis gesetzt.
Grüsse, geTuemII
