[Allegro] Index-Erneuerung: ORG-Menü

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg,

> Andere Fälle von "Korruption" kann man nicht systematisieren, u.U. auch
> gar nicht softwaretechnisch identifizieren, und somit auch keine
> brauchbare Fehlerbehandlung oder -meldung konstruieren.

Es ist zumindest schwierig: Meine Perl-Tools sind durchaus in der Lage
Datensaetze zu identifizieren, an denen index.exe crasht bzw.
Datensaetze verwirft / zerstoert oder einfach nicht findet.

Hier aus dem Gedaechtnis ein paar typische Probleme:

- - Saetze teilweise ueberschrieben (weil a99 Satznummern ueber eine
  "komplette Reorganisation" gerettet hat, Win'9x-Probleme,
  Netzprobleme, moeglicherweise weitere Ursachen)

- - Kategorien enthalten Hex FF (Cut&Paste-Unfaelle), werden trunkiert

- - Saetze enthalten leere #00 (beliebtes Ergebnis aelterer a99-Versionen)

- - Saetze beginnen mit #01 (Vollcrash von a99 folgt, mit PRESTO rettbar)

- - Andere Hierarchiefehler

- - Saetze enden nicht mit CR/LF

- - ALD-Dateien enthalten ein paar MB ASCII 0 (Netzwerkprobleme.
  Unbestaetigt: a99-induziert)


Der erste Fall wurde von Ihnen aus der Sicht von INDEX.EXE beschrieben:
Ein Satz hat eine gesunde Satznummer oder nicht. Korrupte Saetze
zeichnen sich aber gerade dadurch aus, dass nicht klar ist, wo der
Satz anfaengt oder aufhoert. Typisch sind z.B. anschliessend "verklebte"
Datensaetze, also ein Satz, der Truemmer eines anderen enthaelt.




> Zur Feststellung, ob alle internen Satznummern stimmen, gibt es die
> Check-Funktion (h check: "Adressen checken"). Zur weitergehenden
> Feststellung, ob ungültige Feldnummern vorhanden sind, gibt es immer
> noch den Sniffer.

Auch der Sniffer geht davon aus, dass die Saetze gesund sind und
findet daher nur Marginalien wie gesperrte Saetze, ungewoehnliche
Satznummern, undefinierte Kategorien. Die wirklichen Haemmer hat
Sniffer noch nie finden koennen.

INDEX.EXE koennte m.E. etwas defensiver programmiert sein, und
mehr Fehlermeldungen bzw. Abbrueche produzieren, wenn es auf Probleme
stoesst. Allerdings ist es nicht Aufgabe von INDEX.EXE, kaputte
Daten zu reparieren, insofern muss es nicht so defensiv programmiert
sein wie ein Analyse-Werkzeug, sondern darf durchaus davon ausgehen,
dass das, was es da bearbeitet, Datensaetze sind.



> Sie wollen doch sicher nicht vorschlagen, daß man nie eine Erneuerung
> der Datenbankdateien machen sollte, sondern immer nur eine der
> Indexdatei? Das wäre ein extrem konservativ-defensiver Approach, der
> natürlich auch nicht total von der Hand zu weisen ist.

Es gibt Anwender, die traditionell jahrelang nie indexieren. Irgendwann
"spinnt" das System (oder ein Datensatz), und dann wird Reindexierung
versucht. Natuerlich wird man "wrong recno" nicht durch "Index
wiederherstellen" los, aber "komplette Reorganisation" in dem Fall, wo
es bereits Indizien fuer Datenkorruption gibt, halte ich ohne vorherige
Analyse (mindestens mit Sniffer) fuer verwegen: Es gibt zwar eine
gewisse Chance, dass man hinterher eine benutzbare Datenbank hat, aber
es ist keine Voraussage moeglich, was diese enthaelt.

Meine Faustregel ist eigentlich: Wer regelmaessig (alle paar Wochen oder
Monate) reindexiert (Index Wiederherstellen), der kann auch (ein bis
zwei mal im Jahr) eine "komplette Reorganisation" durchfuehren. Alle
anderen sollen lieber (etwa durch "NewMode=0" in der .ini-Datei) auf
maximale Stabilitaet achten und hoechstens anlaesslich eines Versions-
wechsels alle Jubeljahre einmal "Index wiederherstellen" durchfuehren.

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHX6rDhKFJT0F1FsoRAo5WAJ4rviZe5Q6UPE9SNm1ccabdFwBr/wCfTp7A
YrdqyfLhAKkn8q3BjTsRVfQ=
=vAxL
-----END PGP SIGNATURE-----