8999 bei CommitAll

Alle Fragen um die Programmierung, die sich sonst nicht kategorisieren lassen. Von Makro bis Codeblock, von IF bis ENDIF

Moderator: Moderatoren

Antworten
Benutzeravatar
adrian
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 235
Registriert: Mo, 08. Mai 2006 8:58
Wohnort: Aadorf TG
Kontaktdaten:

8999 bei CommitAll

Beitrag 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
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 8458
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 22 Mal
Danksagung erhalten: 91 Mal
Kontaktdaten:

Re: 8999 bei CommitAll

Beitrag 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.
Herzlich,
Tom
Benutzeravatar
adrian
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 235
Registriert: Mo, 08. Mai 2006 8:58
Wohnort: Aadorf TG
Kontaktdaten:

Re: 8999 bei CommitAll

Beitrag 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
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 8458
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 22 Mal
Danksagung erhalten: 91 Mal
Kontaktdaten:

Re: 8999 bei CommitAll

Beitrag 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
Herzlich,
Tom
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2182
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 10 Mal
Danksagung erhalten: 31 Mal

Re: 8999 bei CommitAll

Beitrag von ramses »

Hallo Adrian

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

Gruss Carlo
Benutzeravatar
adrian
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 235
Registriert: Mo, 08. Mai 2006 8:58
Wohnort: Aadorf TG
Kontaktdaten:

Re: 8999 bei CommitAll

Beitrag von adrian »

Hoi Carlo

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

Adrian
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12579
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 3 Mal
Danksagung erhalten: 12 Mal

Re: 8999 bei CommitAll

Beitrag 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.
gruss by OHR
Jimmy
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2182
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 10 Mal
Danksagung erhalten: 31 Mal

Re: 8999 bei CommitAll

Beitrag 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.
Valar Morghulis

Gruss Carlo
Benutzeravatar
adrian
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 235
Registriert: Mo, 08. Mai 2006 8:58
Wohnort: Aadorf TG
Kontaktdaten:

Re: 8999 bei CommitAll

Beitrag 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
Benutzeravatar
adrian
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 235
Registriert: Mo, 08. Mai 2006 8:58
Wohnort: Aadorf TG
Kontaktdaten:

Re: 8999 bei CommitAll

Beitrag von adrian »

Danke Dir Carlo

Dieser Tip hilft mir eventuell bei 2 anderen Kunden.

Adrian
Benutzeravatar
Bertram Hansen
Foren-Moderator
Foren-Moderator
Beiträge: 890
Registriert: Di, 27. Sep 2005 8:55
Wohnort: 51379 Leverkusen
Hat sich bedankt: 11 Mal
Danksagung erhalten: 8 Mal
Kontaktdaten:

Re: 8999 bei CommitAll

Beitrag 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
:wave:
Gruß Bertram
http://www.tobax.de
Mitglied der XUG Cologne
Mitglied der XUG Osnabrück
Beisitzer des Deutschsprachige Xbase-Entwickler e.V.

Solange Kakaobohnen an Bäumen wachsen ist Schokolade Obst!
Benutzeravatar
adrian
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 235
Registriert: Mo, 08. Mai 2006 8:58
Wohnort: Aadorf TG
Kontaktdaten:

Re: 8999 bei CommitAll

Beitrag 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
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14147
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 6 Mal
Danksagung erhalten: 32 Mal
Kontaktdaten:

Re: 8999 bei CommitAll

Beitrag 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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
adrian
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 235
Registriert: Mo, 08. Mai 2006 8:58
Wohnort: Aadorf TG
Kontaktdaten:

Re: 8999 bei CommitAll [Erledigt]

Beitrag 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
Antworten