Seite 1 von 1

8999 bei CommitAll

Verfasst: Mo, 31. Mai 2021 11:40
von adrian
Hallo zusammen

Wir haben bei einem Kunden irgendwelche rechliche Themen, es ist der einzige Kunde mit diesem Fehler welcher auch nicht jedemal auftritt und dies seit einem Server-Wechsel seinerseits.

Aber eventuell hat da einer von Euch einen Tip:
Xbase++ Version : Xbase++ (R) Version 2.00.1334
Betriebssystem : Windows 10 2009 Build 19042
------------------------------------------------------------------------------
oError:args :
oError:canDefault : J
oError:canRetry : N
oError:canSubstitute: N
oError:cargo : NIL
oError:description :
oError:filename :
oError:genCode : 8999
oError:operation : DbCommitAll
oError:osCode : 0
oError:severity : 2
oError:subCode : 5381
oError:subSystem : BASE
oError:thread : 1
oError:tries : 0
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von CLOSEALLDB(1386)
Aufgerufen von MAIN(139)

es sonnigs Grüessli

Adrian

Re: 8999 bei CommitAll

Verfasst: Mo, 31. Mai 2021 12:13
von Tom
Hallo, Adrian.

SubCode 5381 bei Fehler 8999 verweist laut Andreas Gehrs-Pahl, der sich wie kaum jemand sonst mit dem Xbase++-Laufzeitfehlersystem befasst hat, auf einen eher unspezifischen Fehler der DBE. Jedenfalls erklärt er das hier (wo dieser Fehler auch im Rahmen eines Commits auftrat):

http://news.alaska-software.com/readmes ... ata-access (ggf. runterscrollen)

Vielleicht kannst Du genauere Informationen erheben und an Alaska weiterreichen. Möglicherweise hilft es als Workaround, die Workareas einzeln zu selektieren und mit DbCommit() jeweils durchzuschreiben.

Re: 8999 bei CommitAll

Verfasst: Mo, 31. Mai 2021 13:12
von adrian
Danke Dir Tom

Das mit dem Virenschutz haben wir bereits weitergegeben, ob dies umgesetzt wurde wissen wir nicht:

Aber Andreas schreibt am Schluss:
Es sei denn, das Problem ist in irgendeiner Weise reproduzierbar, in diesem Fall könnten Sie
dies an Alaska einreichen, sonst können Sie nicht viel tun, fürchte ich.
Und eben, reproduzierbar ist es eben nicht, 2-3 3 Mal pro Tag von 5 Arbeitsplätzen.

Mal schauen, eventuell kommen wir per Zufall drauf.

Adrian

Re: 8999 bei CommitAll

Verfasst: Mo, 31. Mai 2021 13:20
von Tom
Hallo, Adrian.

Oder Du ersetzt das DbCommitAll() durch sowas:

Code: Alles auswählen

FUNCTION MyCommitAll()
LOCAL nCtr, aWorkSpaceList := WorkSpaceList()
FOR nCtr := 1 TO Len(aWorkSpaceList)
  DbSelectArea(aWorkSpaceList[nCtr])
  DbCommit()
NEXT
RETURN NIL

Re: 8999 bei CommitAll

Verfasst: Mo, 31. Mai 2021 16:42
von ramses
Hallo Adrian

wie wird das Laufwerksmapping gemacht? Per Gruppenrichtlinie oder einzeln auf dem PC?

Re: 8999 bei CommitAll

Verfasst: Mo, 31. Mai 2021 17:10
von adrian
Hoi Carlo

Keine Ahnung, wie gesagt, Anlage ist nicht von uns. Aber spielt dies eine Rolle?

Adrian

Re: 8999 bei CommitAll

Verfasst: Mo, 31. Mai 2021 17:29
von AUGE_OHR
Hi,

es gibt noch eine Situation wo es fehlschlagen kann : Energie-Spar-Massnahmen der Netzwerk Karte.
dies tritt besondere gerne dann auf wenn man "alle Dateien" öffnet ... und die "offen" lässt ...

nach der Mittagspause geht man wieder an den PC und will was machen und beim ersten Datenzugriff "crasht" es.

ich lasse einen Thread auf ein "internes Mail" System laufen was alle 60 Sec. eine Abfrage nach neuen Mails macht ( SEEK )
damit bleibt die Netzwerk Karte "wach" und es gibt keine "open/close" Probleme die damit zusammen hängen.

Re: 8999 bei CommitAll

Verfasst: Mo, 31. Mai 2021 18:26
von ramses
adrian hat geschrieben: Mo, 31. Mai 2021 17:10 Keine Ahnung, wie gesagt, Anlage ist nicht von uns. Aber spielt dies eine Rolle?
Ich hatte schon was irgendwie vergleichbares....

Du hattest geschrieben "Server Wechsel" dabei kam mir folgendes in den Sinn:


Sofern der PC in regelmässigen Abständen immer wieder für kurze Zeit seine Netzlaufwerke verliert kann es daher kommen, dass in der Gruppenrichtlinie für die Windows Domäne beim Netzlaufwerk als Aktion Ersetzen statt Aktualisieren eingestellt ist.

Dieses Problem tritt erst ab Windows 8 und höher auf. Bei diesen Betriebssystem werden die Gruppenrichtlinien in regelmässigen Zeitabständen auch bei einer angemeldeten Benutzersitzung aktualisiert. Dies führt dann zu einer kurzen Trennung der Netzlaufwerke wenn nicht Aktualisieren eingetragen ist. Bei Windows 7 erfolgte eine Abfrage der Guppenrichtlinien nur einmalig bei der Benutzeranmeldung.

Re: 8999 bei CommitAll

Verfasst: Mo, 31. Mai 2021 18:29
von adrian
Hoi Jimmy

Ja, in diese Richtung tippe ich auch, doch dann kommt normalerweise, dass die Verbindung unterbrochen worden ist.

Aber in diesem Fall ist es ein CommitAll(), und dies kommt nur nach einer Funktion welche ja im Voraus die Datenbanken geöffnet hat bearbeitet hat, was ja auch klappte.

Aber ich nehme dies gerne auf.

Adrian

Re: 8999 bei CommitAll

Verfasst: Mo, 31. Mai 2021 18:31
von adrian
Danke Dir Carlo

Dieser Tip hilft mir eventuell bei 2 anderen Kunden.

Adrian

Re: 8999 bei CommitAll

Verfasst: Mi, 02. Jun 2021 10:17
von Bertram Hansen
Hallo Adrian,

Bei meinen Kunden trat dieser Fehler manchmal auch auf. Ich persönlich vermute, dass die Ursache mit dem Netzwerk zusammenhängt. Daraufhin habe ich mir damit geholfen.
Ich fange den Fehler ab und versuche bis zu 10 mal DbCommitAll() auszuführen. Die fehlerhaften Versuche werden auch protokolliert.

Code: Alles auswählen

FUNCTION MyDbCommitAll()
   LOCAL bSaveError := ErrorBlock(), oError := NIL, lRet := .T., nZaehler := 0

   DO WHILE .T.
      ++nZaehler
      ErrorBlock( {|e| oError := e, Break(e)} )
      BEGIN SEQUENCE
         DbCommitAll()
      RECOVER USING oError
         IF nZaehler >= 10
            nZaehler := 0   
            LogDbErrorProtokoll("DBCOMMITALL", ALIAS(), oError:genCode)
         ENDIF   
         ErrorBlock( bSaveError )
         SLEEP(10)
         LOOP   
      END SEQUENCE
      ErrorBlock( bSaveError )   
      EXIT
   ENDDO
   
RETURN lRet

Re: 8999 bei CommitAll

Verfasst: Mi, 02. Jun 2021 11:42
von adrian
Hoi Bertram, danke für den Tip.

Ja, es muss am Netzwerk (wo auch immer) liegen. Aber im Prinzip weigere ich mich, für einen Kunden eine Anpassung zu machen, da wir eine Standard-Lösung haben und diese bei ca. 110 Kunden in Betrieb ist und wir bei keinem anderen dieses Problem haben.

Aber danke für den Tip, werde eventuell für Test Zwecke dies da mal umsetzen.

adrian

Re: 8999 bei CommitAll

Verfasst: Mi, 02. Jun 2021 12:19
von Jan
Hallo Adrian,

ich kann Bertram nur voll unterstützen. Bei meinem Hauptkunden hatten wir nach dem Einbau neuer schneller Server plötzlich massive Fehlermeldungen wie Du. Ich habe dann für alle relevanten Db-Funktionen wie DbSeek, DbAppend, DbRLock und DbRUnLock, usw. nach dem Muster, das Bertram oben gepostet hat, eigene myDb...-Funktionen geschrieben. Mit dem recvover und allem was dazu gehört. Diese Funktionen verwende ich jetzt grundsätzlich in allen meinen Projekten. Das tut mir nicht weh, und ob der Kunde da sonst Probleme hätte interessiert mich nicht. Aber ich habe grundsätzlich meine Ruhe.

Das Umbauen war natürlich simpel. Einfach die Funktionen schreiben, ein projektweites Suchen und Ersetzen der Db-Funktionen gegen die myDb-Funktionen, und alles war gut. Und bei Weiterentwicklungen mußte ich mich nur umgewöhnen statt der Db-Funktionen die myDb-Funktionen zu coden. Das war aber nach wenigen Tagen so im Blut das ich da heute gar nicht mehr drüber nachdenken muß.

Von daher - der Vorschlag von Bertram ist ganz generell der beste Weg für Dich.

Jan

Re: 8999 bei CommitAll [Erledigt]

Verfasst: Mi, 02. Jun 2021 14:17
von adrian
Danke für die Erklärung Jan, dann werde ich dies mal so in die Hand nehmen und prüfen was die folgenden sind.

Danke Euch allen für die Ideen und hoffen wir wieder einmal auf ein persönliches Du auf Du.

Adrian

Re: 8999 bei CommitAll

Verfasst: Fr, 02. Jul 2021 23:37
von azzo
Hallo,
vielleicht schaust du dir diesen Link an:

http://forums.fivetechsupport.com/viewt ... 43#p218536

Ich denke SMB und verschiedene WINDOWS-Versionen ist das Problem.



LG
Otto