Re: Vermische Datensätze

[Robert Fischer]

Liebe Liste,

das Problem, wie manche anderen Datenbankfehler auch, ist nicht eben neu,
wie man aus den div. Mails mit "vor 1,5 Jahren hatten wir ..." ersehen kann.

Meiner bescheidenen Ansicht nach duerfte ein erheblicher Faktor in der
Wiederbelegung von geloeschten Saetzen liegen, was mit der Startoption
" -H0" (= -HNull) leicht (im Startbatch-Aufruf) zu vermeiden ist.

Zusaetzlich ist es eben doch ac-teuflisch, einfach ueber ACP eine
Neuorganisation zu starten, ohne vorher wenigstens mit dem SNIFFER die DB
geprueft zu haben.

Die zierlichsten Probleme in den letzten Jahren waren wirklich die der
"Vermischten Saetze" und die gelegentlich bemerkten geloeschten
Indexeintragungen. (Das sind Saetze, die zwar in der DB enthalten, aber
nicht auffindbar sind - das gibt leicht Dubletten!)

Nach meiner Erkenntnis kann bei einer "Neuorganisation" ohne weitere
Pruefung durchaus eine  erhebliche Menge Datenschrott unbemerkt erhalten
bleiben.

Die einzige Aktion, der ich vertraue, ist die Neu-Indexierung nach Pruefung
der DB mit dem SNIFFER, der Analyse der belegten Kategorien (z.B mit RDWR
und noch etwas Muehe mit dem AURORA-Editor) und der konsequenten
Aufbewahrung von LOGs, dem Einsatz von #99e / #99n und am Besten der
lueckenlosen Fuehrung von IDs in #00 / #09, sodass etwaige Geister-Saetze
gelegentlich gefunden / rekonstruiert werden koennen.

Bevor wieder einzelne allegroLogen ueber mich herfallen, moechte ich zur
Ehrenrettung schreiben, dass ich besonders in instabilen Netzen mit echten
DB-Fehlern konfrontiert war und diese ohne Ansehen dieser allegro-fremden
Tatsache zu geschrieben habe.

Von einer Entlueftung wuerde ich immer absehen, ich halte die Neuindexierung
immer fuer besser, auch wenn sie mehr Arbeit macht (gibts keine Wochenenden
??).

Die Entlueftung hat den Nachteil, dass die von B.E. erwaehnte Diagnose:

Man nehme alle geloeschten Saetze aus dem Index 1 (F6 // RET) in eine
Ergebnissmenge und exportiere diese z.B. mit I-1.APR in eine Datei (ist
diese groesser 0 Byte, schellen alle Alarmglocken!!!)


eben nicht funktioniert. (Weil die geloeschten Saetze weg sind.)

Also, langer Rede kurzer Sinn: -H0 im Aufruf bringts, da koennen die
geloeschten Saetze echt oder falsch sein, wie ac will.

Zwei oder drei Dinge moechte ich doch Allen ans Herz legen:

1. Todsuende
Man ueberarbeite eine DB ohne Sicherungskopie und am Besten auf einem
Verzeichnis, wo alte ALDs mit gleichem DB-Namen uebrig geblieben sind ( -
dublette / aehnliche Satze garantiert)

2. Todsuende
Beim Ueberspielen / Kopieren / Sichern lasse man eine oder mehrere
ALD-Datein unter den Tisch fallen (WRONG RECNR garantiert).

Das kann auch unbewusst geschehen, wenn das Kopieren innerhalb eines Batches
aus Platzgruenden nicht entsprechend ausgeführt wird. Da gibts dann eben
u.U. keine Fehlermeldung zu sehen.

3. Todsuende
Das waere was fuer das Programm INDEX:
Man erfasse fleissig Hierarchien und lasse die #01 unter der #02
gelegentlich weg oder erfasse nur diese (mit eine Zeichen: also #01 1 ) und
sonst keine weiteren Kats in einem Untersatz.
(Eine fehlerhafte Indexierung ist bei aelteren!!! Versionen gelegentlich
aufgetreten.)

4. Todsuende
Man will zwar Rat von der Liste (oder privat von allgroLogInnen), hat aber
kein Geld fuer eine aktuelle
Lizenz und demzufolge auch keine aktuelle AC-Version (V14...  - o o, neulich
eben :-((((.)


Ich versteh das schon, darf das aber ja doch mal sagen (weil: arm sind wir
alle!).
Wozu bleiben wir dann DB-Format- und Paramaessig abwaerts-kompatibel???

Das wars.
Je weniger Arbeit und Nerverei beim DB-TUEV, desto besser!

Mit freundlichen Gruessen
& C u in BS

Robert Fischer Berlin
rfb at blinx.de
************************************************************