Rolf, wenn der Rlock nie klappt, dann hast du so einen Hänger...
Pack das Ganze in eine For-Schlaufe mit 3-5 Versuchen und einem kleinen Wait dazwischen.
nicht das ich wüßte. Aber wenn ich auf EoF() stehen würde, dann würde der doch garnicht erst in die Schleife reingehen, oder? Mich irritiert bei der ganzen Sache, das es erstens ansich immer funktioniert. Und das der zum unlock nur kommen KANN, wenn das locken vorher auch funktioniert hat. Ansich sollte also kein Grund bestehen, warum das unlocken nicht klappen sollte. Wobei die Fehlermeldung natürlich mal wieder diese unglaublich hilfreiche 8999 ist ...
hmmm ... Virenscanner. Die sind natürlich immer irgendwie ein Problem. Aber warum könnte der ausgerechnet bei einem unlock dazwischen funken? Klar hat man schon Pferde kotzen gesehen. Aber verstehen tu ich das trotzdem nicht wirklich.
schön wars ... Mein Problem ist, das man die Software auch als Demo runterladen kann. Und dann steht im mir zugemailten Errorlog halt nicht drin, wer das gewesen ist (außer das es die Demo war). Ich kann mich mit dem Anwender leider nicht in Verbindung setzen, weil ich einfach nicht weiß wer das war.
AUGE_OHR hat geschrieben:dann poste doch bitte das gesamte Errorlog.
Wieso? Da fehlt nur die Zeile mit der Angabe der exe. Die eben halt auf einen lokalen Laufwerksbuchstaben hinweist. Und eben die Liste der prg mit den Codezeilen. Nix außergewöhnliches.
AUGE_OHR hat geschrieben:Frage : wurden Threads verwendet ?
Bei mir hatte nur eine Umstellung des Codes (andere Ablauf, oder so) geholfen. Da ich inzwischen aber vollständig auf SQL umgestellt habe kann ich da nicht mehr nachsehen.
Markus,
da war sicherlich der Virenscanner ursächlich für Deinen Fehler - Änderung am Code, neu kompiliert, neue Prüfsumme und leicht anderes Verhalten - schon klappt es wieder...
Mist! Gerade kam wieder der gleiche Fehler rein, anderer Kunde, andere Code-Stelle, aber wieder beim DbRUnLock(). Da muß ich ganz dringend irgendwas machen, sonst werden meine Kunden mich hassen ...
Wäre es sinnvoll und möglich, eine eigene MyDbRUnlock()-Funktion zu schreiben, in die ich ein eigene Fehlerbehandlung per BEGIN SEQUENCE einbaue? Das müßte doch wohl eine Möglichkeit sein, diesen Fehler sauber abzufangen.
Würde es alterntaiv eventuell helfen, vor dem DbRUnLock() ein DbSkip(0) oder ein DbCommit() einzubauen? Oder würde das nur den Zeitpunkt der Fehlermeldung verlagern?
Hallo.
Ich hatte die selben Fehler, mal create index, mal unlock. Nicht richtig reproduzierbar.
Bei mir war es definitiv der Virenscanner, und zwar die Aktivitätskontrolle.
Wenn das Programm und die Daten lokal waren, ist der Fehler sehr selten aufgetreten.
Wenn die Daten im Netzwerk lagen (egal mit gemappten Laufwerk oder \\IP) angesprochen,
dann trat der Fehler häufiger auf. (Auch wenn die Daten auf der NAS liegen, also kein Server)
Ich bat mal einen Kunden den Scanner abzuschalten, seither hatte er kein Problem mehr.
Selbst wenn nur ein Programm auf eine Datei zugreift passiert der Fehler. Hat also nichts
mit Mehrplatzanwendung zu tun.
Noch eine Eigenart hatte ich festgestellt.
Indexdatei gelöscht und Programm gestartet. Ist beim Indexaufbau dann auch abgebrochen, allerdings
war der Index richtig vorhanden.
Das Programm beendet und den Index benutzt hat dann funktioniert.
Ich hatte die Indexe gelöscht und das Programm gestartet. Nach dem 10. Start waren dann alle Indexe erstellt und das
Programm hat funktioniert. (Ich baue dann nur noch die nicht vorhandenen Indexe auf)
Wenn ich im Programm meine Funktion fmyreindex() aufgerufen habe, und die Indexe alle gelöscht und neu aufbauen wollte,
dann ist das Programm nie durchgelaufen, da ich die Indexe nach dem Abbruch beim Programmstart alle wieder gelöscht wurden.
Bei einem der vielen Indexe ist das Programm dann abgestürzt.
Beim Aufbau vieler Indexe tritt der Fehler dann auch "zeitnah" auf und man kann mal an den Stellschrauben vom Virenscanner arbeiten.
Ich hab an anderer Stelle im Forum schon mal darauf hingewiesen.
Hoffe mal das hilft.