APPEND + Index
Moderator: Moderatoren
APPEND + Index
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?
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?
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: APPEND + Index
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
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: APPEND + Index
NTX oder CDX ? welche OS() ? Local oder Netzwerk ? welche Xbase++ Version ?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?
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
Jimmy
- brandelh
- Foren-Moderator
- Beiträge: 15706
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 70 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: APPEND + Index
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 !
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
Hubert
Re: APPEND + Index
Am Anfang noch nicht viel mir dann ein aber hatte noch nicht zur Lösung des Problems geführt..Hast Du nach dem Appenden und Datenschreiben mal ein Commit() gemacht?
Es existiert keine DbeLoad-Anweisung im mir vorliegenden Programm -> Standard DBFNTX von XBase.NTX oder CDX ?
WinXP - lokal - 1.90.331welche OS() ? Local oder Netzwerk ? welche Xbase++ Version ?
Zum Start des Programmes habe ich folgenden Code eingefügt:waren ALLE, zur DBF zugehörigen Indexe, vor dem APPEND BLANK geöffnet ?
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()
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.mit RLOCK() / NetErr() ?
Nach der Schleife habe ich den Aufruf DbCommit() stehen.COMMIT oder SKIP(0) oder GOTO(nRec) ?
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..
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2832
- Registriert: Fr, 08. Feb 2008 21:29
- Hat sich bedankt: 98 Mal
- Danksagung erhalten: 13 Mal
Re: APPEND + Index
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?
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 S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: APPEND + Index
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
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
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.