Inoffizielles deutsches Xbase-Forum

Hallo - ich mal wieder

ich hatte gestern ein sehr seltsames Verhalten meines Programm-Codes.
Ich hatte eine Routine geschrieben mit der ich Datensätze in eine DB schreibe.
Danach sollen die aktualisierten Werte mittels temporärer angelegter DBF angezeigt werden.

Seltsam daran war, dass dann einige der Records die ich mit APPEND BLANK hinzufügte da waren zum wieder auslesen und andere nicht.

Ich habe jetzt herausgefunden, dass das Problem gelöst ist, indem ich nach der Schleife mit dem APPEND neu indexiere mit INDEX ON.

Ist das so, dass man nach jedem APPEND den Index der DBF manuell neu aufbauen muss?

Das hört sich so an als ob die Sätze nicht ganz korrekt gespeichert würden. Hast Du nach dem Appenden und Datenschreiben mal ein Commit() gemacht? Oder DbGoTo(RecNo())?

Jan

Wonderer hat geschrieben:Ich habe jetzt herausgefunden, dass das Problem gelöst ist, indem ich nach der Schleife mit dem APPEND neu indexiere mit INDEX ON.

Ist das so, dass man nach jedem APPEND den Index der DBF manuell neu aufbauen muss?

NTX oder CDX ? welche OS() ? Local oder Netzwerk ? welche Xbase++ Version ?

waren ALLE, zur DBF zugehörigen Indexe, vor dem APPEND BLANK geöffnet ?
mit RLOCK() / NetErr() ?
COMMIT oder SKIP(0) oder GOTO(nRec) ?

Antwort auf deine Frage : NEIN

genau das ist sicher wei beim letzten Mal ein Problem mit den verschiedenen Indexdateien.

Viele öffnen nur die, welche aktuell gebraucht werden. Oft in verschiedener Reihenfolge ... da ist Ärger vorprogrammiert.

Indexdateien entweder CDX 1 je DBF mit Tags oder NTX mehrere sollten in einer Funktion (immer gleich im ganzen Programm) geöffnet werden, die z.B. auch sicher stellt dass eine Fehlt.
Ein Parameter könnte dann auch den Neuaufbau erzwingen.

Wenn die Indexe offen waren, dann kommt sowas nicht vor, solange nicht ein Hardware oder Metadatenproblem dazu kommt...

Wenn aber ein Windows 7 PC auf eine Netzfreigabe geshared zugreift, dann muss man die cache Werte abstellen ... SMB2 Fix oder so war der Suchbegriff dazu.

PS: nach APPEND BLANK müsste man auch netterr() abfragen !

Hast Du nach dem Appenden und Datenschreiben mal ein Commit() gemacht?

Am Anfang noch nicht viel mir dann ein aber hatte noch nicht zur Lösung des Problems geführt..

NTX oder CDX ?

Es existiert keine DbeLoad-Anweisung im mir vorliegenden Programm -> Standard DBFNTX von XBase.

welche OS() ? Local oder Netzwerk ? welche Xbase++ Version ?

WinXP - lokal - 1.90.331

waren ALLE, zur DBF zugehörigen Indexe, vor dem APPEND BLANK geöffnet ?

Zum Start des Programmes habe ich folgenden Code eingefügt:

mit RLOCK() / NetErr() ?

Vor der Schleife mit den APPENDs habe ich zuerst ein FLock gehabt. Jetzt habe ich nach dem Lesen im Handbuch statt APPEND BLANK die Methode DbAppend die das Sperren für den Datensatz gleich mit vornimmt. NetErr() habe ich dann nachdem es nicht funktionierte mit eingefügt gleich hinter die Anweisung für das Anfügen eines neuen Datensatzes.

COMMIT oder SKIP(0) oder GOTO(nRec) ?

Nach der Schleife habe ich den Aufruf DbCommit() stehen.

Wann ist ein Skip(0) sinnvoll oder erforderlich für den weiteren korrekten Programmablauf?

Danke, auch an dich Hubert.. Ich arbeite erstmal weiter, da das Problem mit dem Neuaufbau des Index gelöst ist - hab morgen so was ähnliches wie eine Deadline..

Hallo,


ein dbskip(0) schreibt die Dateibuffer auf die Platte zurück, bzw. (da wird es meist verwendet) sorgt dafür, dass die aktuellen Dateiwerte erneut eingelesen, was in einem Netzwerkumfeld wichtig ist, wenn der Datensatz von einem anderen Benutzer (Thread) geändert wurde.

Wenn ein Datensatz mit dbAppend() bzw. APPEND BLANK angehangen wird, dann wird dieser Datensatz in allen offenen Indexdateien eingetragen. Ausnahme: Das entsprechende Schlüsselfeld hat das UNIQUE Attribut, und es gibt bereits einen Datensatz, bei dem das Schlüsselfeld leer ist. Wenn Du aber im nächsten Schritt die Felder mit Werten beschickst, sollte das kein Problem darstellen.

Sind die Datensätze auch dann nicht vorhanden, wenn Du die Datei OHNE Index liest?

Georg,

DbSkip(0) war immer state of the art. Aber in den letzten Diskussionen ist darauf hingewiesen worden, daß Alaska das eventuell wegrationalisiert hat. Und man besser ein DbGoTo(RecNo()) nehmen sollte.

Jan