Verlautbarung 83 der Entwicklungsabteilung 961127
----------------
Speicherfehler moeglich, wenn faelschlich Mehrplatz eingestellt
---------------------------------------------------------------
Es wurde eine Fehlerquelle aufgedeckt, die auch bei V14c einen
Speicherfehler produzieren kann. Dabei wird der Anfang eines
voellig unbeteiligten Satzes ueberschrieben, dieser also in der
Regel zerstoert.
Zwar ist der Fall recht unwahrscheinlich, wir sollen aber dennoch
umfassend darueber informieren.
Der Fehler tritt NUR auf, wenn 3 Bedingungen zusammentreffen:
1. auf einem Einzelplatzsystem im Mehrplatzmodus gestartet wurde UND
2. mindestens 1 verlaengerter Datensaetz in diesem Modus gespeichert wurde
3. geloeschte Saetze vorhanden waren (//-Eintraege im Register 1),
wobei mindestens einer der verlaengerten Saetze in einen geloeschten
Satz gespeichert wurde.
1. Bis zu diesem Punkt ist noch nichts zerstoert. Erst wenn ein weiterer
verlaengerter Satz gespeichert wird, mit ungefaehr derselben Laenge,
tritt eine Ueberschreibung auf.
Durch Neuindexierung kann das Problem noch vermieden werden.
Im allgemeinen merkt man beim ersten Speichervorgang, dass etwas nicht
stimmt: es dauert ungeheuer lange, und anschliessend sind die Register-
eintraege trotzdem nicht da. Man korrigiert das Problem, indexiert neu
und danach kann nichts mehr passieren. Es kann aber der Teufel wollen,
dass schon die erste Speicherung ein verlaengerter Satz ist UND ein passender
Leersatz vorhanden war.
Was passiert eigentlich dabei genau?
Konstruieren wir eine Situation:
Satz A ist 100 Zeichen lang und wird auf 190 Zeichen verlaengert.
Es gibt einen Leersatz B, der 200 Zeichen lang ist. Dieser hat also
den Schluessel //00200. Das Programm findet diesen Schluessel und
speichert den Satz auf den Platz von Satz B. Jetzt muss //00200 entfernt
werden, das klappt aber nicht. Ausserdem muss //00100 mit Nummer B
neu gespeichert werden, das klappt auch nicht, aber das macht nichts.
Das Problem ist: die Aenderungen in der TBL funktionieren, nur die
in der .ADX nicht. Wir haben anschliessend unveraendert eine Index-
eintragung //00200 fuer Satz B, Satz B ist jetzt aber ein Satz mit
nur 100 Byte, denn Satz A nimmt ja seine Nummer auf den neuen Platz
mit und Nummer B wandert auf den frueheren Platz von A.
Wenn jetzt erneut ein Satz mit knapp 200 Byte kommt, wird er auf den
falschen Platz gesetzt (wo nur 100 Byte frei sind) und ueberschreibt
dadurch den Anfang des unbeteiligten Satzes, der hinter Leersatz B kommt.
Abhilfe: schon allein um die fehlenden Registereintraege zu bekommen,
muss man neu indexieren, wenn einem ein falscher Start mit
Einzelplatzmodus passiert ist UND ein Datensatz gespeichert
wurde. Dann stimmen die Leerschluessel wieder.
Also: CockPit "Organisieren / Index erneuern"
bevor man weiterarbeitet.
Anschliessend kann man mit Sniffer die Satztabelle kontrollieren,
um ganz sicher zu gehen. Wird ein fehlerhafter Satz gefunden,
muss man sich um seine Reparatur bemuehen.
Sichere Vermeidung:
Einzelplatzmodus vermeiden (aleo keine Option -S), dafuer aber
grundsaetzlich SHARE starten, bevor man mit "allegro" arbeitet.
Wenn man feststellt, dass alle Aufrufe korrekt mit Option -S versehen
sind, braucht man im Einzelplatzmodus keine Befuerchtungen zu haben!
Sind Sie unsicher, ob in der Vergangenheit immer mit -S gestartet wurde,
dann hetzen Sie Sniffer auf die Datenbank.
Fuer V15 wird versucht, das Problem generell zu loesen.
MfG B.E.