[Allegro] Datenverlust durch Standardeinstellungen

Thomas Berger ThB at Gymel.com
Mi Nov 21 12:37:32 CET 2007


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

Lieber Herr Eversberg, liebe Liste,

in einer Datenbank bin ich einer merkwuerdigen Dublette auf der Spur,
verbunden mit dem Verschwinden eines anderen Satzes.

Plausibelste Erklaerung dafuer ist, dass die Datenbank Anfang August
einer "kompletten Reorganisation" unterzogen wurde, Mitte Oktober
wurde ein bearbeiteter Satz dann unter seiner alten Satznummer (von vor
August) gespeichert. In der .ini-Datei steht SaveResults=1, das
ist zwar nicht die Default-Einstellung, jedoch die Vorgabe aus der
beispielhaften a99.ini im Programmverzeichnis (die unbedingt
auf etwas weniger gefaehrliches geaendert werden sollte):

Sobald eine volle Reorganisation stattfindet (oder eine Entlueftung)
sind die meisten aufbewahrten Ergebnisse voellig wertlos, und
Rueckgriff auf sie durch a99 fuehrt unweigerlich zu Datenverlust
beim Speichern.

Die Plausibilitaetskontrolle von a99 hilft da nicht, der Satz, der
faelschlicherweise ueberschrieben wird, ist meistens jahrelang nicht
angefasst worden und daher fast nie neuer als der zu speichernde. Eine
nur leicht verbesserte Sicherheit bekaeme man, wenn nicht nur das
Aenderungsdatum verglichen wird, sondern stets auch das
Ersterfassungsdatum, und zwar auf absolute Gleichheit (viele Altsaetze
in der Freien Wildbahn haben aber nur 8 Zeichen lange Datumsstempel
oder ueberhaupt keine Ersterfassungsdaten)

[Wenn man zwei Datenbanken etwa namens "cat" regelmeassig benutzt,
kommen deren aufbewahrte Ergebnisse ebenfalls maechtig miteinander
in Konflikt und Daten der einen Datenbank werden munter in die
andere zurueckgespeichert und umgekehrt. Das sollte hoffentlich
bekannt sein]

Der Administrator kann auch nicht anlaesslich des Reorganisierens auf
allen (plausiblerweise ausgeschalteten) Arbeitsplaetzen die (in den
ihm unzugaenglichen TEMP-Verzeichnissen liegenden) existierenden
Aufbewahrungsdateien von a99 loeschen.

a99 braucht m.E. unbedingt einen Mechanismus, mit dem es beim Start
erkennt, dass aufbewahrte Ergebnisse vorliegen, die Datenbank jedoch
neue Satznummern bekommen hat. In dieser Situation muss a99 die
aufbewahrten Ergebnisse verwerfen, es koennte aber das Ausfuehren einer
Not-Routine anbieten, um noch nicht gespeicherte Aenderungen und
Neusaetze in ein update-Faehiges Format umzuwandeln.


Folgende Moeglichkeiten fallen mir dazu ein:
- - selbstprogrammiert im _start.flx: Der Administrator setzt eine
  Datei ins Datenverzeichnis, wenn die existiert und aufbewahrte
  Ergebnisse da sind, muss etwas passieren mit anschliessendem Neustart
  Hier gibt es viele Detailprobleme, etwa ob Dateien geoeffnet sind
  und nicht so einfach geloescht werden koennen (oder regelt "erase
  off" exakt die problematischen Saetze?). Vor allem aber gibt es das
  logische Problem, dass diese Merkdatei im Datenverzeichnis unendlich
  lange bestehen bleiben muss, denn ein Mitarbeiter koennte noch
  zwischengespeicherte Ergebnisse gehabt haben, bevor er ein Sabbatjahr
  nahm: Kehrt er 2009 zurueck, gibt es wieder ein Problem.

- - a99-unterstuetzt: Man benoetigt einen cstring, der das Datum der
  letzten Sitzung liefert (und der kann auch den seinerzeitigen
  Speicherort der Datenbank vermerken). org.flx bzw. Administrator
  setzen anlaesslich satznummernrelevanter Reorganisationen einen
  Zeitstempel in einer Datei im Datenverzeichnis, _start.flx kann
  die beiden Zeitstempel vergleichen (und auch den seinerzeitigen
  Speicherort mit dem aktuellen Datenverzeichnis, damit endlich sicher-
  gestellt ist, dass die aufbewahrten Ergebnisse auch wirklich zur
  aktuellen Datenbank gehoeren) und im Fall einer Abweichung a)
  warnen, b) Ausspeicherung der Ergebnisse anbieten c) die gemerkten
  Ergebnisse verwerfen und notfalls d) a99 restarten.

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

iD8DBQFHRBh7hKFJT0F1FsoRAjWwAJsF/xaw0X3Wj56KBsYIPkzb/3I+cACfapRD
RYDbtORfQbRiTGPQ4zDGWMI=
=yuBo
-----END PGP SIGNATURE-----



Mehr Informationen über die Mailingliste Allegro