[Allegro] Datensatz über "Zack" importiert und beschädigt

[Thomas Berger]

Lieber Herr Kaut,

[gerade sehe ich die Antwort von Herrn Eversberg zum Thema, seinen
Hinweisen sollten Sie zuerst nachgehen. Sie arbeiten aber mit
V31.4 und mit PRESTO und Cockpit, wenn mich nicht alles taeuscht?]


> Den Datensatz habe ich bearbeitet (mit Signatur und Schlagworten versehen) 
> und es sah auch (bis zum Abspeichern) alles ganz normal aus.
> 
> Dann der Schock. Der Datensatz enthält plötzlich Kategorien eines alten 
> Datensatzes von 2006 (s.u. kursive Felder) und der alte Datensatz ist 
> beschädigt und unvollständig.
> 

...
517 Literaturverz. S. 42 - 43


>  Datenbank: CAT  Datei#: 1  Satz#: 90465   V31.4   Länge: 1335, frei: 65
> 
> #00 01026843
> #15 Gutenberg-Museum Mainz

...
#81 Enth. 1. Selbstbiographie und 2. Briefwechsel in Fraktur
#81mLiteraturverz. S. 42 - 43


> Alter Datensatz:
> 
> recn=3645, wrong recn=1936028513, ci=101, file#=1  rad=1917756   press any 
> key..
> .
> #30a2.4.8
> #31 Kupferstecher / Julius Thaeter / Biographie
> #31pThaeter, Julius <Kupferstecher> / Biographie
> #37 ger
> #39 zsgest. aus schriftl. Nachlaß von Anna Thaeter
> #40 Thaeter, Julius
> #49 Thaeter, Anna
> #50 Thaeter, Julius
> #74 Frankfurt am Main
> #75 Alt
> #76 1887
> #77 167, 185 S. : Ill.
> #81 Enth. 1. Selbstbiographie und 2. Briefwechsel in Fraktur
> #90 Schaar 26
> #90218:4°/1993 a [079]
> #91 06/814
> #99e20060523
> #99n20060523
> 
> 
> Bisher hatten wir im Museum nie Probleme bei Hunderten von importierten 
> Sätzen!
> 
> Wie kann das kommen?


Es gab wohl einen Datensatz, der in der cat_1.ald unmittelbar vor
dem Satz "Schaar 26" lokalisiert, als Leersatz gekennzeichnet und
im Index vermerkt war, aber eine Inkonsistenz hat: Seine Laenge
ist angeblich groesser als der zwischen seinem Anfang und dem
Anfang des Satzes "Schaar 26" verfuegbare Platz.

Abspeichern Ihrer gezack'ten Aufnahme nach Anreicherung um Schlagworte
etc. hat dazu gefuehrt, dass diese neue Aufnahme umgespeichert werden
musste, da am bisherigen Ort nicht mehr genuegend Platz frei war.
Suche ergab nun zufaellig den obigen Problemsatz, der neue Satz wurde
dorthin gespeichert (dessen Satznummer ist nun "getauscht" und weist
auf die Speicherstelle mit der frueheren Version der gezackten Aufnahme),
dabei wurde dann der Anfang des "Schaar 26"-Satzes ueberschrieben.

Das erklaert allerdings nicht, warum *gleichzeitig* noch ein zweites
Problem auftritt, dass naemlich das Datensatzende des neuen Satzes
fehlt und daher vom dahinter gespeicherten Datensatz weitere Felder
dazugesammelt werden (und bei Dopplung vorher gelesene ueberblenden).

Daher (das Auftreten solcher unabhaengigen Doppelfehler ist objektiv
sehr viel unwahrscheinlicher) vielleicht doch eher ein einzelnes Problem
und zwar mit dem neuen Datensatz? Bei Copy&Paste ins PRESTO-Fenster
gelangten frueher manchmal Zeichen 255 in die Daten, auf die allegro
nicht gut reagiert (allerdings nicht soo ungnaedig...)

Ich erinnere mich ganz dunkel an folgendes Problem: Wenn in der .api-
Datei nachgeladen wurde und durch einen Parametrierfehler vergessen
zurueckzustapeln, dann geriet einiges bezuglich interner Satznummer
und auch -Laengen in Unordnung und es kam definitiv zu Datenverlust,
moeglicherweise mit aehnlichem Fehlerbild wie von Ihnen heute
beschrieben (alles sehr vage - es ist heiss heute und ich berichte
von Erlebnissen aus 2006 oder so). Gerade bei PRESTO, wo im Moment
des Editierens die alten Schluessel berechnet werden, wuerde so
ein Problem dazu fuehren, dass waehrend der Bearbeitung unbemerkt
bereits das Rueckspeichern an einen falschen Ort "vorgemerkt" ist...

Wie dem auch sei: Um weiteren Schaden zu vermeiden, sollten Sie
den jetzigen Zustand der Datenbank sichern und anschliessend an die
Reparatur gehen, sprich eine "volle Reorganisation" (index -f7)
durchfuehren. Anschliessend nicht mehr vorhandene Saetze muessten
Sie dann rekonstruieren bzw. immer noch kaputte vorsichtshalber
loeschen und komplett neu erfassen.

Die Stabilitaet wird erhoeht, wenn Sie die Updates bei ZACK und
ggfls. auch Ihre PRESTO-Sitzungen so einstellen, dass Leersaetze
ignoriert werden, d.h. die Aufrufe mit dem Schalter -N0 versehen.

Ansonsten ist V31.4 eine der besonders kurzlebigen "Fruehjahrsversionen"
von allegro gewesen (2.5.2011), die ich als eher instabil auffassen
wuerde. Fuer die 16bit-Module mag das aber gar nicht stimmen.
V33.5-01 letztes Jahr war die letzte Version, die mit 16bit-Programmen
ausgeliefert wurde, tendenziell sollten Sie sich vielleicht daran
orientieren und ansonsten ernsthaft ueberlegen, auf die Bearbeitung
mit a99 umzusteigen.


viele Gruesse
Thomas Berger