Netzwerkfehler 3043 - Wie wäre es mit einer Retry-Funktion?

[Doming]

Hallo,

ich hatte heute den Fall, dass bei uns zwei Rechner Netzwerkprobleme hatten und mit Fehler 3043 - Ihr Netzwerkzugriff wurde unterbrochen. Schließen Sie die Datenbank, und öffnen Sie sie erneut, um den Vorgang fortzusetzen. vor sich hinvegetierten.
Meine erste Idee war jetzt, diesen Fehler einfach mit Application.Quit abzukürzen, dann müllt mir der Rechner jedenfalls nicht mehr zyklisch meine Fehlertabelle voll ;-)
Allerdings, muss man denn immer gleich den Stecker ziehen, nur weil jemand kurz aufs Netzwerkkabel getreten ist?
Eine KI schlug mir nun vor, alle Querys usw vorher abzusichern, quasi beim Öffnen also zu checken, ob die Verbindung noch da ist:

Code [Auswählen] Erweitern

Public Function OpenQuerySafe(qName As String) As Boolean
    On Error GoTo Fehler
   
    DoCmd.OpenQuery qName
    OpenQuerySafe = True
    Exit Function

Fehler:
    If Err.Number = 3043 Then
        Sleep 1000
        Resume
    Else
        MsgBox Err.Number & " - " & Err.Description
        OpenQuerySafe = False
    End If
End FunctionWas mir ein bisschen missfällt: Normalerweise, wenn ich mehrere Abfragen in einer Prozedur aufrufe, setze ich erst ein set cdb = CurrentDb vorweg und greife dann nur noch auf die cdb zu. Das wäre dann natürlich mit der obigen Funktion nicht mehr so.
Ich fand die Idee an sich jetzt gar nicht so schlecht, möchte aber gerne mal Eure Sichtweise erfahren.

Gruß
 Doming

[Knobbi38]

Hallo Doming,

grundsätzlich brauchen DBs stabile Netzwerkverbindungen, weil die Clients i.d.R. das sehr übel nehmen. Probleme mit der Hardware kannst nicht mit Software lösen. Deshalb mein Rat: sorge für vernünftige und stabile Hardware.

Warum nicht so einfach ein "Retry" eingebaut werden kann und ob der Vorschlag von der KI wirklich sinnvoll ist, kannst du ja mal selber überlegen.

Knobbi38
 

[Doming]

Die Hardware liegt nicht in meiner Hand, ich bin nur ein kleines Rädchen in einem 200-Seelen-Betrieb, der "sowieso am Liebsten alle Access-Datenbanken in den Wind schießen möchte".
Nur dass diese Datenbanken schon seit Jahren (und länger) ihren Dienst versehen und viele Nutzer daran gewöhnt sind, wird dann gerne vergessen.
Nur ein Teil der DB sind von mir, und auch bin ich mit dem Programmierstil des Erstellers nicht ganz glücklich, aber er hat vor Jahren das Unternehmen verlassen und ich sehe jetzt zu, dass die Anpassungswünsche der Nutzer eingepflegt werden.
Dass die Netzwerkverbindungen unterbrochen wurden habe ich erst gemerkt, seit dem ich die "Fehlerbehandlung" Resume Next dahingehend geändert habe, dass die Fehler vorher in eine Tabelle geschrieben werden. Sie sind glücklicherweise auch nur selten und da dachte ich mir, dass so ein Retry vielleicht besser sinnvoller ist, als eine DB stumpf zu beenden.

Gruß
 Doming

[Bitsqueezer]

Hallo,

also in den neueren Access-Versionen sollte das Schließen der Datenbank bei Netzwerkproblemen nicht mehr nötig sein (außer in besonders kritischen Fällen), da Access die Netzwerkverbindung wieder aufbauen kann, was es früher eben nicht konnte, da gab es nichts außer Anwendung beenden und neu starten, oft auch mit Totalabsturz und nur noch Taskmanager als Lösung.
Ich würde also erst mal schauen, ob Access auf dem neuesten Stand ist. Bei den älteren wird Dir auch kaum ein Code-Trick helfen. Dazu kommt, daß es Dir auch nicht hilft, eine neue Query zu öffnen und so zu testen, ob die "Verbindung noch da ist" - weil Access bei MDB/ACCDB im Gegensatz zum früheren ADP für JEDES geöffnete Objekt (Tabelle/Abfrage) eine eigene Verbindung zum Backend aufbaut. Dann hast Du mit OpenQuery vielleicht wieder eine Verbindung, aber die, die Du brauchst, ist immer noch tot. Oder Du prüfst es vorher und DIESE Verbindung ging - aber danach die eigentliche nicht mehr, weil das Problem dann erst auftritt.

Grundsätzlich würde ich allerdings auf die "Wiederherstellungsfähigkeit" von Access nicht wirklich vertrauen und im Fall lieber die Anwendung neu starten. Nur so ein Bauchgefühl...

Du kannst natürlich mit ADO verbindungslosen Recordsets arbeiten, da hast Du (dieses) Problem nicht (dafür ein paar andere), ist aufwendig und auch fehleranfällig. Ansonsten bleibt Dir nur der Umstieg auf z.B. .NET- oder Webandwendungen, die verbindungslos arbeiten. Aber so eine Access-Anwendung schreibt man halt auch nicht "mal eben" um.

Gruß

Christian