Das Forentreffen 2018 findet am 20./21. April in Dresden statt. Weitere Infos hier
Zur Homepage des Deutschsprachige Xbase-Entwickler e. V.
Xbase++-Wiki des Deutschsprachige Xbase-Entwickler e. V.

APPEND + Index

Eigentlich ist mir die Frage peinlich, aber es kann sonst niemand helfen ... :)

Moderator: Moderatoren

Antworten
Wonderer
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 107
Registriert: Do, 06. Jul 2006 13:24

APPEND + Index

Beitrag von Wonderer » Di, 05. Apr 2016 8:05

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?

Benutzeravatar
Jan
Foren-Administrator
Foren-Administrator
Beiträge: 12224
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Kontaktdaten:

Re: APPEND + Index

Beitrag von Jan » Di, 05. Apr 2016 8:16

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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 10520
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: APPEND + Index

Beitrag von AUGE_OHR » Di, 05. Apr 2016 8:20

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 :!:
gruss by OHR
Jimmy

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 13753
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: APPEND + Index

Beitrag von brandelh » Di, 05. Apr 2016 8:44

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 !
Gruß
Hubert

Wonderer
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 107
Registriert: Do, 06. Jul 2006 13:24

Re: APPEND + Index

Beitrag von Wonderer » Di, 05. Apr 2016 10:16

Hast Du nach dem Appenden und Datenschreiben mal ein Commit() gemacht?
Am Anfang noch nicht :roll: 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:

Code: Alles auswählen

FLock()
if .not. file ("NAME.NTX")
 index on FIELD1 to IDX_1
 index on FIELD2 to IDX_2
endif
set index to IDX_1, IDX_2
DbUnlock()
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.. :)

georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1920
Registriert: Fr, 08. Feb 2008 21:29

Re: APPEND + Index

Beitrag von georg » Di, 05. Apr 2016 10:56

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?
Liebe Grüsse aus der Eifel,

Georg

Benutzeravatar
Jan
Foren-Administrator
Foren-Administrator
Beiträge: 12224
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Kontaktdaten:

Re: APPEND + Index

Beitrag von Jan » Di, 05. Apr 2016 11:24

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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.

Antworten