[Allegro] a99: Probleme mit a99 unter Novell 6.5 (SP 5)

[Thomas Berger]

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

Lieber Walter,

> Nun zum Problem: A99 stürzt häufig beim Speichern ab und zwar bei der
> Bearbeitung der Indexeinträge. Das Programm reagiert nicht mehr und
> muss
> über den Taskmanager beendet werden. Die TBL ist dann gesperrt. 

"Bearbeitung der Indexeintraege" ist aber nur eine Hypothese von Dir?


> Dies scheint einmal mit der Größe der Datenbank zu tun zu haben: Bei
> kleinen Testdatenbanken tritt das Problem nicht auf, obwohl die gleichen
>  Parameterdateien vewendet werden.
> 
> Zum anderen scheint es mit der Zahl der erzeugten oder geänderten
> Indexeinträge zu tun zu
> haben. So tritt das Problem ausschliesslich bei Neukatalogisierungen
> oder bei Kopien von Datensätzen auf 
> und nicht beim Speichern geänderter Titel auf.
> 
> Die alten DOS Programme haben das Problem nicht, also kann es auch
> nicht an irgednwelchen
> Defekten in der Indexdatei liegen.
> 
> Wurde jemand aus dem Kollegenkreis unter mit einem ähnlichen Phänomen
> konfrontiert oder
> sind Lösungsmöglichkeiten bekannt  ?


Ein ziemlich aehnliches Problem hatte ich letztes Jahr: Hier geriet
a99 beim Umspeichern von Datensaetzen in eine Endlosschleife: Mit
filemon (von sysinternals.com) konnte ich schoen sehen, wie der
Index stets an derselben Stelle konsultiert wurde, dann die .tbl-
Datei stets an denselben 4 Bytes etc.: Der erste relevante Leersatz
lag in der falschen Datei, statt den naechsten zu untersuchen, fing
a99 von vorne an. (Hier ist das Problem ~moeglicherweise~ anders
gelagert, die Bearbeiter erlebten das Problem aber so, dass sie
Probleme mit einem Satz hatten und diesen daher immer wieder neu
eingaben, immer wieder mit Absturz).

Die Endlosschleife liess sich durchbrechen, indem man waehrend des
Haengens ein PRESTO startete: Dessen Zugriff auf den Schluessel ___
lag nahe genug am fraglichen Bereich "//" im Register 1, um
kurzzeitig einen Lesefehler fuer a99 zu generieren, es gab dann
scheinbar keinen Leersatz mehr und alles ging normal weiter ;-)

Der Fehler liess sich weiter nicht klaeren (klar ist, dass man
mindestens zwei .cLD-Dateien braucht, was naturgemaess eine etwas
groessere Datenbank bedeutet), er war stabil (ich konnte ihn an
der konkreten tagelang beobachten und konnte das Problem beim
Umspeichern anderer als dem urspruenglich gemeldeten Problemsatz
reproduzieren), jedoch liess er sich an der frisch indexierten
Datenbank leider nicht reproduzieren, erst nach einiger Zeit mit
echten Bearbeitungen wieder. Moeglicherweise war also "nur" die
interne Struktur des Index korrumpiert (die fragliche Datenbank
wurde ausschliesslich mit a99 bearbeitet), allerdings so subtil,
dass das Probem nur Speichervorgaenge unter a99 betraf (evtl.
haben PRESTO und Konsorten noch einen internen Test auf diese
Situation ausserhalb des gesunden Bereichs, den a99 nicht mehr
hat. Das war jetzt natuerlich alles Spekulation).

Abhilfe bestand darin, mit -N0 bzw. der .ini-Einstellung NewMode die
Beruecksichtigung von Leersaetzen zu unterbinden (das ist fuer
groessere Netzwerkdatenbanken stets empfehlenswert, denn das Suchen
nach Leersaetzen in der passenden Datei ist bei allegro extrem
ineffizient) (und ausserdem ueber -n bzw. InputFileNr dafuer zu
sorgen, dass Neusaetze in einer Datei landen sollen, in der noch
Platz ist).

viele Gruesse
Thomas Berger

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

iD8DBQFFNIPchKFJT0F1FsoRAlScAJ9C3zFvuYeuETOGVGaJGLMRS2cFRQCfUgbw
MDRduSzxyn6FqXdrs3lNUic=
=5fy0
-----END PGP SIGNATURE-----