oError:genCode : 8999

[satmax]

Kennt das Problem jemand? Hat mir gerade 2 Stunden gekostet...

Code: Alles auswählen

AUFAKT->(dbappend())
IF NETERR()
     tdMsg("Datenbankfehler aufakt 1642")
ENDIF
AUFAKT->AUNR = AUFTRAG->AUNR
DbCommit()
nHere := recno() // Wird diese Zeile unmittelbar nach dbAppend() bzw. vor dem dbCommit 
                         // aufgerufen kommt es immer zu den unten angefürten 8999 Fehler 

Code: Alles auswählen

Xbase++ Version     : Xbase++ (R) Version 1.90.355
Betriebssystem      : Windows 7 06.02 Build 09200
------------------------------------------------------------------------------
oError:args         :
oError:canDefault   : J
oError:canRetry     : N
oError:canSubstitute: N
oError:cargo        : NIL
oError:description  : D
oError:filename     : 
oError:genCode      :       8999
oError:operation    : DbCommit
oError:osCode       :          0
oError:severity     :          2
oError:subCode      :          0
oError:subSystem    : BASE
oError:thread       :          4
oError:tries        :          0

[AUGE_OHR]

hi,
versuch mal die Änderung im Code

Code: Alles auswählen

AUFAKT->(dbappend())
IF NETERR()
     tdMsg("Datenbankfehler aufakt 1642")
ENDIF
AUFAKT->AUNR = AUFTRAG->AUNR


// DbCommit()
// mit Alias
AUFAKT->( DbCommit() )
nHere :=  AUFAKT->( recno()  )

// nHere := recno() // Wird diese Zeile unmittelbar nach dbAppend() bzw. vor dem dbCommit 
                         // aufgerufen kommt es immer zu den unten angefürten 8999 Fehler 

p.s. mit oder ohne

Code: Alles auswählen

// DbeInfo(COMPONENT_ORDER,DBE_LOCKMODE,LOCKING_EXTENDED)

[Jan]

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

Was mir im Moment auffällt ist, das sowohl commit als auch RecNo() ohne Alias stehen, während Du weiter oben mit arbeitest. Versuch doch mal, diese beiden Zeilen ebenfalls mit Alias auszuführen.

Jan


PS: Oh, seh gerade, das Jimmy die gleiche Idee hatte

[Hans Zethofer]

Code: Alles auswählen

AUFAKT->(dbappend())
IF NETERR()
     tdMsg("Datenbankfehler aufakt 1642")
ENDIF
AUFAKT->AUNR = AUFTRAG->AUNR

vielleicht trifft NETERR() zu , dann sollte man nicht nur eine Info-/Fehlermeldung ausgeben sondern auch dementsprechend reagieren (Abbrechen).

[satmax]

Das habe ich alles erst umgebaut nachdem ich Probleme hatte. Normal uns auch hier verwende ich immer den alias. Ist auch schon wieder richtig gestellt.

Das eigentliche Problem war, es wurde ein Datensatz angelegt aber das Replace wurde nicht richtig ausgeführt: "AUFAKT->AUNR = AUFTRAG->AUNR" ursprünglich "REPLACE AUFAKT->AUNR WITH AUFTRAG->AUNR", nicht mal "REPLACE AUFAKT->AUNR WITH 4711" wurde richtig gespeichert.

Man konnte im Debugger sehen, das der Wert zugeteilt wird, bei der nächsten DB Operation war der Wert nicht mehr im Record: "AUFAKT->(DbUnlock())", (oder commit, dbskip(0)...). Das Datensatz blieb aber laut Debugger gleich. Und manchmal kam der Fehler 8999. Immer wieder ein Reindex zwischendurch hat nichts gebracht.

Teilweise war in der Fehlerbeschreibung hunderten Zeichen Datenmüll "oError:description : D 123456§$%&~...." gefüllt

Erst seit ich die Zeile "nHere := AUFAKT->(recno())" weiter nach unten verlagert habe geht alles wieder normal...

[Jan]

Machst Du inkrementelles compilieren? Dann mach doch mal ein komplettes rebuild. Ich habe manchmal auch total merkwürdige Sachen, so wie Du das beschreibst mit Wert wird trotz eindeutiger Zuweisung nicht gespeichert. manchmal hilft dann ein rebuild, als ob sich da intern irgendwo was verknotet hat. Ein einfaches compilieren des betreffenden Codes nützt dann nichts.

Jan

[satmax]

Wusste gar nicht das XPP inkrementelles compilieren kann! Aber ja, wenn es so anfängt lösche ich zwischendurch mal alle *obj, ich denke das sollte reichen.

Gruß
Markus

[satmax]

@Jimmy

Ich hatte es mit und ohne versucht.

Gruß
Markus

[AUGE_OHR]

Erst seit ich die Zeile "nHere := AUFAKT->(recno())" weiter nach unten verlagert habe geht alles wieder normal...

nach dem NetErr() müsste es schon gehen.

nun steht ja in der Xbase++ Hilfe :

Wenn die Datei in einem Netzwerk oder von zwei Xbase++ Applikationen auf einem Rechner gleichzeitig benutzt wird, versucht DbAppend() automatisch den neuen Datensatz zu sperren.

wenn man eine DBF im SHARE Modus alleine betreibt dann wird IHMO nicht automatisch eine RLock() verwenden weil (theoretisch) nicht notwendig.
erst wenn ein gleichzeitiger Zugriff erfolgt wird auf "Ops Level 2" runter-geschaltet und dann ist die Wahrscheinlichkeit eines 8999 grösser.

trotz allen würde ich auf sicher gehen und den Code so erweitern

Code: Alles auswählen

// use full UNC Path
LOCAL cHost  := "\\A-hp\ALASKA\0"
LOCAL cFile  := "TESTOPS.DBF"
...
   nLast := TESTOPS->( LASTREC() )
   //
   // Test APPEND BLANK
   //
   ? ""
   ? "starte DBF APPEND BLANK, please wait ..."
   nStart := SECONDS()
   FOR i := 1 TO nMax
      TESTOPS->( DbAppend() )
      IF NetErr()
         TONE(1234)
         nError++
      ELSE
         nRec := TESTOPS->(RECNO())
         IF TESTOPS->(DbRLock(nRec))
            REPLACE TESTOPS->TESTSTRING   WITH STRZERO(i) // Replicate("A",10)
            REPLACE TESTOPS->TESTNUM      WITH RECNO()
            REPLACE TESTOPS->TESTDATE     WITH DATE()
            REPLACE TESTOPS->TESTTIME     WITH TIME()
            REPLACE TESTOPS->TESTNODE     WITH cNode

            TESTOPS->(DbRUnlock(nRec))
            //
            // need for Win7 "original" if other have SP1 RC
            //
            TESTOPS->(DbSkip(0))
         ELSE
            #IFDEF __XPP__
               Msgbox("DbRLock("+LTRIM(STR(nRec))+") Error")
            #ELSE
               Alert("DbRLock("+LTRIM(STR(nRec))+") Error")
            #ENDIF
         ENDIF
         IF (i % (nMax/100)) == 0
            nStop := SECONDS()-nStart
            nper  := nStop/i
            @ 8,0 Say "Prozent "+LTRIM(STR(i/(nMax/100),10,0 ))+"% per Record "+LTRIM(STR(nper))+" Sec."
         ENDIF
      ENDIF
   NEXT
   nStop  := SECONDS()-nStart

p.s. sollte das APPEND zu lange dauern siehe http://support.microsoft.com/kb/825433

[satmax]

Danke, ich werde meinen Code nochmals dahingehend sichten und eventuell anpassen.

Gruß
Markus

[brandelh]

nun steht ja in der Xbase++ Hilfe :

Wenn die Datei in einem Netzwerk oder von zwei Xbase++ Applikationen auf einem Rechner gleichzeitig benutzt wird, versucht DbAppend() automatisch den neuen Datensatz zu sperren.

wenn man eine DBF im SHARE Modus alleine betreibt dann wird IHMO nicht automatisch eine RLock() verwenden weil (theoretisch) nicht notwendig.

Sorry, aber das ist Quatsch !

Entweder man öffnet eine Datei EXCLUSIVE und muss sich um Netzsperren nicht kümmern (die Datei ist ja gerade schon gesperrt),
oder man öffnet geshared und dann muss man bei jedem Schreibzugriff den Satz (RLock) oder die Datei (FLock) sperren.
Tut man es nicht, gibt es einen Laufzeitfehler (Sperre nötig) - auch wenn man als einziger die Datei geöffnet hat !

APPEND BLANK und dbAppand() verhalten sich genau so !

Der Fehler 8999 ist allerdings gerade keiner der wegen Sperrproblemen auftreten sollte (dafür gibt es ja NetErr() ...).

Offensichtlich war das Laufzeitsystem nicht in der Lage alles sauber zu handlen wenn dieser Fehler auftritt, warum ... das ist dann die Frage

[AUGE_OHR]

... aber das ist Quatsch !

meinst du die Aussage im Handbuch

Die Funktion DbAppend() verwendet standardmäßig die Funktion RLock(), um den neuen Datensatz zu sperren.

oder die Formulierung von "gleichzeitig" ?

Entweder man öffnet eine Datei EXCLUSIVE und muss sich um Netzsperren nicht kümmern (die Datei ist ja gerade schon gesperrt),
oder man öffnet geshared und dann muss man bei jedem Schreibzugriff den Satz (RLock) oder die Datei (FLock) sperren.
Tut man es nicht, gibt es einen Laufzeitfehler (Sperre nötig) - auch wenn man als einziger die Datei geöffnet hat !

APPEND BLANK und dbAppand() verhalten sich genau so !

GENAU das sage ich doch das man sich NICHT darauf verlassen kann das nach APPEND der RLock automatisch klappt wenn kein "gleichzeitiger" Zugriff vorliegt !

[georg]

Hallo, Jimmy -


zum einen ist Dein Zitat unvollständig:

...
nun steht ja in der Xbase++ Hilfe :

Wenn die Datei in einem Netzwerk oder von zwei Xbase++ Applikationen auf einem Rechner gleichzeitig benutzt wird, versucht DbAppend() automatisch den neuen Datensatz zu sperren.

Da steht nämlich noch was dahinter:

If the record cannot be locked, the append is not successful. A runtime error is generated which is caught by a default error routine and nothing in the file is changed. The default error handling routine handles this error by changing the value returned by NetErr() to .T. (true) and allowing the application to continue.

wenn man eine DBF im SHARE Modus alleine betreibt dann wird IHMO nicht automatisch eine RLock() verwenden weil (theoretisch) nicht notwendig.

Diese Vermutung ist schon abenteuerlich von der Formulierung her, und ich vermute, dass sich deshalb einige daran "stossen". Bei mir in der Hilfe steht vorne "Multi-user access:", und das ist der entscheidende Punkt. Wenn die Datei shared geöffnet ist, wird automatisch nach einem dbAppend() der neue Datensatz gesperrt.

Überdenke Deine Interpretation noch einmal, und dann würde mich interessieren, was denn Deiner Meinung nach passiert, wenn DREI Benutzer gleichzeitig zugreifen, unter Berücksichtigung der Aussage in der Dokumentation - das Beispiel aus der Dokumentation soll beispielhaft Scenarien beim Multi-user access beschreiben, aber keine Ausschliesslichkeit festlegen.

Der Aufwand, festzustellen, wie viele Programme / Instanzen gleichzeitig auf die Datei zuzugreifen, ist m.E. deutlich höher - daher würde ich als Programmierer von Xbase++ immer einen dbRLock() nach einem dbAppend() ausführen. Anders macht es keinen Sinn.

[georg]

Hallo,


da mir das ganze keine Ruhe gelassen hat, hier ein Beispiel - kurz, klein, knackig:

Code: Alles auswählen

FUNCTION Main()
   USE DEMO ALIAS DEMO NEW SHARED
   dbAppend()
   ?dbRLockList()
RETURN (.T.)

Die Demo.dbf ist leer, und was meinst Du, kommt als Ausgabeergebnis von ?dbRLockList()?

{ 1}

Selbst bei einem Benutzer wird mit dem dbAppend() auch ein dbRLock() ausgeführt - q.e.d.

[Jan]

Georg,

aber auch nur wegen dem SHARED. Mach das Ganze mal mit EXCLUSIVE, dann wird das Ergebnis ein anderes sein.

Jan

[satmax]

Kleine Anmerkung von mir: ich öffne alle Datenbanken im SHARDED Modus (außer natürlich bei Wartungsarbeiten wie PACK/REORG).

[georg]

Hallo, Jan -


meine Aussage bezog sich auf Jimmy's Schlussfolgerung aus dem unvollständig zititerten Dokumentationstext, auf nichts anderes. Und da geht es um SHARED geöffnete Dateien.

[AUGE_OHR]

hi,

hier kommt jetzt einiges durcheinander ...

zunächst mal reden wir über Netzwerk Umgebung und nicht über Lokalen Zugriff ( und wenn per UNC-Path bitte).
dann kommt die Frage nach NetErr() was im Fall eines nicht gelungenen Sperre ein .F. geben "soll" ...

wenn eine DBF mit SHARE im Netzwerk geöffnet wird und es der erste ( einzige ) Benutzer ist
dann ist es "Exclusive Locks" wo man beim APPEND,wie auch beim GhostRec, "eigentlich" kein extra locking benötigt.
NetErr() "müsste" immer .F. (echt) zurück geben.

erst wenn ein weitere Benutzer zugreift wird auf "Level 2 OpLocks" geschaltet und dann ist ein RLock() zwingend erforderlich.
hier könnte nach einem APPEND ein NetErr() mit .T. kommen.

was aber wenn genau die Umschaltung von "Exclusive Locks" nach "Level 2 OpLocks" erfolgt und der Cache geleert werden sollte ...

deshalb sieht mein oben dargestelltes dual-fähige Demo ein DbRlock() nach einem DbAppend() vor.

[AUGE_OHR]

nun haben wir über DBF gesprochen und das SMB Verhalten bekommt man ja auch mit Cl*pper in Griff.
Der Unterschied liegt IMHO im sperren/updaten der Indexe und der Verwendung von o:datalink.

beim Einstieg in Xbase++ mit v1.3 hatte ich ständig bei Navigation im XbpBrowse() Probleme mit 8999 und DbSkip() oder DbGoto() während TBrowse liefen
Da ich nicht weiter kam nahm ich die Devcon 2002 NH, USA als Anlass mich direkt mit den Personen von Alaska in Verbindung zu setzen.

Alaska interpretiert "dirty read", was für ein gemeinsames lesen notwendig ist, anders als Cl*pper.
insbesondere FieldBlock() / FieldWBlock() (siehe c:\ALASKA\XPPW32\Source\SYS\Blocks.prg) macht ja einen SET/GET Codeblock !

es ist in einem Browse meistens nur "lesen" notwendig ... und für "schreiben" muss man eine Sperre ausführen ...
nun sollte es ja beim reinen Navigieren nichts ausmachen aber wer auf sicher gehen will sollte IMHO den GET Teil mit NIL bestücken.

nun gibt es noch einen Unterschied zwischen TBrowse() und XbpBrowse() : den Cache

wenn man sich den DbSkipper() von TBrowse() im Debugger ansieht werden exakt so viele Bewegungen ausgeführt die für eine Bildschirm Seite notwendig sind.
Bei XbpBrowse() sind es viel mehr Bewegungen ... da wird noch was im "voraus" gelesen ...
was nun wenn sich Daten geändert haben die schon gelesen wurden oder der "Ops Level" sich geändert hat ?

zugegeben mit den Jahren hat Alaska das Problem besser in Griff bekommen aber mit SMB2 tauchte dann das lokale ( \LanmanWorkStation )
"Directory Notify" Problem auf -> Alaska SMB2-Patch mit den 3 Registry Schlüsseln "abschalten" aber das ist noch eine anderes Thema .

[brandelh]

zunächst mal reden wir über Netzwerk Umgebung und nicht über Lokalen Zugriff ( und wenn per UNC-Path bitte).
dann kommt die Frage nach NetErr() was im Fall eines nicht gelungenen Sperre ein .F. geben "soll" ...
wenn eine DBF mit SHARE im Netzwerk geöffnet wird

hier kommst du mit "modernen Windows Besonderheiten" und gesharten Dateien durcheinander

Zu behaupten ein LOCK wird nur im NETZWERK und nur beim ZWEITEN Benutzer benötigt ist schlicht falsch !

Auch wenn du eine lokale Datei mit SHARE öffnest und etwas schreiben willst (replace), gibt es eine Fehlermeldung ohne RLOCK / FLOCK - wahrscheinlich aber erst beim nächsten SKIP (im Unterschied zu Clipper).
Die von dir häufig aufgeführten SMB/CACHE Problematiken kommen später dazu, aber grundsätzlich muss eine geSHAREt geöffnete Datei (egal wo sie liegt) vor dem Schreiben gesperrt werden.
APPEND BLANK ist ein Schreibzugriff, der aber den RLOCK() automatisch durchführt, wenn es möglich ist. Wenn es nicht möglich war, wird neterr() .t.

Warum könnte also ein APPEND BLANK fehlschlagen, auch wenn die Datei auf einem lokalen Laufwerk liegt ?

Code: Alles auswählen

select 1 
use datei shared
neterr() -> .f.
flock()
select 2
use datei shared
neterr() -> .f.
append blank 
neterr() -> .t.

[AUGE_OHR]

Warum könnte also ein APPEND BLANK fehlschlagen, auch wenn die Datei auf einem lokalen Laufwerk liegt ?

Xbase++ unter Win7/8

Zu behaupten ein LOCK wird nur im NETZWERK und nur beim ZWEITEN Benutzer benötigt ist schlicht falsch !

wo liest du das ???

"eigentlich" kein extra locking benötigt. NetErr() "müsste" immer .F. (echt) zurück geben.

ein APPEND BLANK / Rlock(), wenn ich alleine bin, "müsste" immer gelingen.
Erst beim zweiten Benutzen können SMB Probleme auftauchen die ein locking verhindern könnten.

da nun Markus (Satmax) aber wohl alleine gearbeitet hat der Hinweis das sich Xbase++ DbAppend()
unter Win 7/8 sich nicht nicht so verhält wie Cl*pper.

Markus hat das Phänomen geschildert das der Datensatz zu fehlen "scheint".

hierbei hat er nun "normalen" Cl*pper Code verwenden wobei er sich darauf verlässt das nun ein Rlock() bestehen würde
wie unter Cl*pper üblich. da er das Problem mit RECNO() hatte habe ich es mit dem Source aus meiner SMB2 Demo
verglichen und mir fiel auf das er zwar NetErr() hatte ( ohne weiter Behandlung ) aber kein explizites DbRlock(nRec)
nach dem DbAppend() wofür ich RECNO() verwendet habe was ja ging.

APPEND BLANK ist ein Schreibzugriff

der einen erfolgreichen Sperr Vorgang erfordert die danach bestehen bleiben sollte und NetErr() = .F. zurück gibt.

was aber wenn NetErr() = .T. ?
weil APPEND BLANK nicht ausgeführt wurde oder weil RLock() nicht gelang ?
hier sollte man sich dann die Ergebnisse der DBF von Cl*pper und Xbase++ ansehen.

Netzwerk "locking" :

wie ich im SMB2 Thread dargestellt habe ( dort gibt es auch den vollen Source ) "fehlt" bei Xbase++ ein solcher Datensatz
des 1st. Client wenn er auf "Level 2 OpLocks" umschalten und den Cache leeren soll.
das Ergebnis von NetErr() = .T. beruht dann auf ein fehlgeschlagenes APPEND BLANK ( weil Datensatz nicht vorhanden )

Lokal SMB2 :

unter SMB2 ist noch ein Cache dazu gekommen den man mittels SMB2 Patch "ausschalten" soll um das eigentliche Problem zu umgehen ...
http://technet.microsoft.com/en-us/libr ... 10%29.aspx

da sich die 3 Registry Einträge auf "\LanmanWorkstation" beziehen geht es also um lokale SSD / HDD Aktionen.

ein lokales APPEND BLANK sollte ja keine SMB Probleme bereiten ... aber da gibt es noch den Index
ich sagte ja "scheint" zu fehlen ... wenn man die DBF mit (defekten) Index öffnet ...
wenn man den Index löscht und in die lokale DBF sieht ist dieser Datensatz mit Inhalt doch vorhanden ?!
ein NetErr() = .T. kommt hier also nicht vom APPEND BLANK sondern weil das sperren für den Index nicht richtig ausgeführt wurde

Cl*pper Applikationen, was man über eine Shell starten muss, haben das Phänomen nicht ... auch ohne SMB2 Patch.
auch der Norton Commander (!) hat beim anlegen/löschen/moven keine Probleme in der CMD Shell... Update funktioniert.

es muss also an der fehlenden "Directory Change Notifications" liegen worauf sich die 3 Registry Einträge
beziehen welche Xbase++ (und andere Sprachen auch) nicht "kennt" aber wohl die CMD Shell.

jetzt gibt es aber eine Ausnahme und das sind ge"share"te Ordner die man per UNC-Path anspricht.
man arbeitet lokal aber trotzdem nach Netzwerk SMB Bedingungen und damit funktioniert es IMHO auch ohne SMB2 Patch.

[Jan]

Jimmy,

ich frage mich, was diese Argumentation eigentlich soll. Wenn eine dbf shared geöffnet wird, dann wird ein DbAppend() IMMER sofort locken. Muß es ja auch. Denn es könnte ja ein zweiter User vorbeikommen wollen, der dann auch auf diesen Satz zugreifen will. und dann muß dieser neue Satz auf jeden Fall gegen Überschreiben gesichert sein. Von daher ist es unsinnig zu behaupten, das müsse erst bei einem zweiten User erfolgen.

Und was ist der Unterschied bei einem DbAppend() auf einem XP-Rechner und einem 7-Rechner? Da ist keiner, solange das nicht im Netz hängt, das SMB2 macht, und die dbf ebenfalls im Netz hängt.

Jan

[brandelh]

Warum könnte also ein APPEND BLANK fehlschlagen, auch wenn die Datei auf einem lokalen Laufwerk liegt ?

Xbase++ unter Win7/8

Meine Frage war retorisch, und die Antwort dass Win7/8 daran schuld sein können ist schlicht falsch.
Unter jedem sauber arbeitenden Betriebssystem wird in meinem obigen Beispiel der zweite append blank fehlschlagen, da der 2. Dateizugriff durch den ersteln LOCK blockiert wird.
Egal ob es der gleiche Benutzer/Programm ist, egal ob LOKAL oder im NETZ - deine zweite Antwort bestätigt, dass dir das klar ist

APPEND BLANK ist ein Schreibzugriff

der einen erfolgreichen Sperr Vorgang erfordert die danach bestehen bleiben sollte und NetErr() = .F. zurück gibt.

aber deine dauernde Erwähnung, dass alles mit SMB2 / Win7/8 im NETZWERK zusammenhängt, erweckt bei Neueinsteigern den Eindruck, dass ein LOCK erst beim zweiten Benutzer im Netzwerk nötig wird. Das ist aber schlicht falsch !

Ich will nur darauf hinweisen, dass jede Datei die NICHT exclusive geöffnet wird, bei jedem Schreibzugriff immer gesperrt werden muss, entweder mit RLock()/FLock() oder automatisch bei dbAppend() / APPEND BLANK oder geänderter Locking Einstellung der DBE. Auch auf einem Rechner ohne Netzwerkkarte.

[Leon]

Wird ein Replace nicht mit ":=" vorgenommen?

Also statt:

AUFAKT->AUNR = AUFTRAG->AUNR

AUFAKT->AUNR := AUFTRAG->AUNR

[Scarmo]

@Leon
Ich denke auch, dass dies allenfalls zur Fehlermeldung geführt hat...

Gruss
Marco