Inoffizielles deutsches Xbase-Forum

Gerade bekomme ich eine Fehlermeldung rein:

Sprachen-Version : 1.90.355
Betriebssystem :Windows 7 06.01 Build 07601 Service Pack 1
------------------------------------------------------------------------------
oError:args :
oError:canDefault : .T.
oError:canRetry : .F.
oError:canSubstitute: .F.
oError:cargo : NIL
oError:description : D
oError:filename :
oError:genCode : 8999
oError:operation : DbRUnlock
oError:osCode : 0
oError:severity : 2
oError:subCode : 0
oError:subSystem : BASE
oError:thread : 1
oError:tries : 0

Was soll ich dazu sagen? Passiert ist das in solch einer Situation: Wie kann sowas denn passieren?

Jan

Guten Morgen Jan

Ich mache das immer so
keine Probleme bisher.

Hallo!

benötigst du unbedingt ein "DbRUnlock()" ?
verwende doch einmal nur ein DbUnlock()

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.

Jan, stehst du auf Eof?

Ich benutze den normal nur mit Recno()

Ansonsten Virenscanner ?

Hallo Herbert,

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 ...

Jan

Hallo Klaus,

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.

Jan

...immerhin ist nicht Montagmorgen
Der Virenscanner wird eher bei Unlock motzen, denn beim Lock erfolgte noch keine Aenderung.

Hallo Herbert,

das ist natürlich ein Argument.

Jan

Laut Hilfe müsste DbRUnLock() ohne Parameter das gleiche tun wie UNLOCK oder DBUNLOCK(), wenn man

PRG hat geschrieben: UNLOCK
UNLOCK ALL
dbunlock()
dbrunlock()

übersetzen läßt, folgt daraus diese Funktionen ...

PPO hat geschrieben: dbUnlock()
dbUnlockAll()
dbunlock()
dbrunlock()

beim UNLOCK wird tatsächlich alles geschrieben, was vorher noch im cache war.

Dieser Fehler verweist in aller Regel auf eine Datei- oder Indexkorruption.

ich würde auf Netzwerk tippen ...

p.s. das "original" XppError.LOG sagt sehr wenig ... wenn man wüsste ob der ALIAS noch aktive ist ...

Jimmy,

das Errorlog sagt mir, daß das Programm lokal ausgeführt wurde.

Abgesehen davon ist das Programm zwar netzwerkfähig, aber wird in 99,9 % immer am Einzelplatz ausgeführt.

Jan

Tom hat geschrieben:Dieser Fehler verweist in aller Regel auf eine Datei- oder Indexkorruption.

http://de.wikipedia.org/wiki/Korruption
Ja, so ist alles klar.

Seriös: Hast du den Virenscanner deaktivieren können?

Hallo Herbert,

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.

Jan

Jan hat geschrieben:das Errorlog sagt mir, daß das Programm lokal ausgeführt wurde.

dann poste doch bitte das gesamte Errorlog.

Frage : wurden Threads verwendet ?

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 ?

Antwort: Ja klar. Wieso?

Jan

Hallo Jan,

ich hatte vor ca. 1 Jahr ein ähnliches Problem, du hast mir geantwortet:

Eine Eigenheit von 8999 liegt darin, selten wirklich die Codezeile auszuwerfen die Schuld daran ist.

Hier der Thread: http://xbaseforum.de/viewtopic.php?f=32&t=7531#p83658

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...

Viele Grüße,
Martin

Das ist leicht möglich, seit der SQL Umstellung kenne ich solche Probleme nicht mehr.

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 ...

Jan

satmax hat geschrieben:Das ist leicht möglich, seit der SQL Umstellung kenne ich solche Probleme nicht mehr.

bei Cl*pper v5.2e arbeitet SMB "sauber" unter Win7/8x ...
aber da gibt es auch keine Threads die zusätzliche Ops Locking Probleme verursachen

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?

Jan

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.

Gruß
Bernd

Hallo.
Nachdem die Indexe fehlerfrei erstellt wurden, trat auch der Fehler mit unlock nicht mehr auf.
Gruß
Bernd