[Allegro] [viel] update-Probleme

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

fuer Datensaetze habe ich stets das "echte" Update mit seinen
Steuermoeglichkeiten bevorzugt, aktuell hatte ich aber einen
Fall, wo in einer vorher exportierten Tabelle Ergaenzungen
vorgenommen waren (eine bestimmte Kategorie mit variablen
Inhalten), ueber einen Perl-Einzeiler habe ich diese Tabelle
ins ADT-Format konvertiert und wollte die dann per
"update" in a99 durch den Bediener einlesen lassen.

Konkret enthielt die ADT-Datei jeweils die Identnummer, die
zu ergaenzende Kategorie, eine Leerzeile und so weiter fuer
die folgenden Datensaetze. Eingelesen werden sollte es durch
Eingabe von

x set u400\update <Dateipfad/Dateiname>

Das hatte in Tests bei mir auch funktioniert, im realen System
gab es dann beim Abspeichern (alle bearbeiteten Daten in die
Datenbank) Meldungspaerchen "Sorry, jemand anders war schneller
und hat den Satz inzwischen geaendert" und "Trotzdem speichern".
Daraufhin musste die Aktion abgebrochen werden (bei nachtraeglichen
Tests stellte sich heraus, dass jeder Satz das Problem hatte).

Der Unterschied zwischen den beiden Installationen laesst
sich auf folgendes zurueckfuehren:

Die nicht funktionierende hatte eine neuere Version von
offcheck.flx, die mit "f1nd #1" beginnt (das war ja als Workaround
fuer ein im uebrigen immer noch existierenes Initialisierungs-
problem der Register eingefuehrt worden). Der Aenderungs-
datumsstempel dieses Satzes (bzw. allgemein der beliebigen
Aufnahme, die beim Ausloesen der Aktion gerade aktuell
ist) hat sich in alle upgedateten Saetze perpetuiert,
insofern war die Abspeicherverweigerung rechtens. Irgendwie
wird dieses Datum allerdings "gemerkt", es brachte nichts,
vorher eine Aufnahme ganz ohne Aenderungsdatum anzusteuern...

Die funktionierende Version hingegen funktionierte auch
nur in der Testsituation: Dort wurde das Update gestartet,
ohne dass je ein Satz geladen worden war, sobald jedoch
jemals mindestens einer mit Aenderungsstempel geladen worden
ist, war das Verhalten auch nicht anders.

Der Fehler ist also: Hat der "Update-Satz" aus der Offline-
Datei keinen Aenderungsstempel, fingiert a99 einen aus
irgendwelchen Zwischenlagern vorher angezeigter Saetze,
wegen Modus "4" gilt der dann auch fuer den Updatesatz und
ist typischerweise in Konflikt mit dem vorhandenen Aenderungs-
stempel. (Modus "300" hingegen beruecksichtigt ihn korrekterweise
nicht, so dass unklar ist, ob er ueberhaupt fingiert wurde).

Wenn hier repariert worden ist, muessten uebrigens als
Resultat eines update auch "gruene", also faktisch
unmodifizierte Saetze moeglich sein, oder irre ich mich da?

Meiner Meinung nach ist es uebrigens bereits vom Ansatz her
verfehlt, in einem Update-Fall den konkreten Aenderungsstempel
fuer den a99-Plausiblitaetstest heranzuziehen: Egal, was nach dem
Merge ueberhaupt im Datensatz steht, es sollte stets ein beim
lesenden Zugriff auf die Datenbank !!!separat!!! gemerkter
Zeitstempel mit dem der live-Datenbank im Moment des Speicherns
verglichen werden: Dann ist halbwegs gewaehrleistet, dass
Datenbank und abzuspeichernder Offlinespeicher noch dieselbe
*Version* des Datensatzes meinen (und dazu waere es wesentlich
geschickter, eine MD5-Summe ueber den ganzen Live-Datensatz zu
bilden, als sich auf den Inhalt einer speziellen Kategorie
zu verlassen, die zudem bei $ abgeschnitten wird und u.U.
anhand antiker Setzungen in der .CFG-Datei noch staerker
trunkiert wird).

Nur um eventuellen Einwaenden vorzubeugen: Wenn der obige
Fehler repariert ist, dann koennte argumentiert werden dass
damit alles funktioniert, bzw. (man denke an den Fall, dass
die zu ladenden Daten komplette Datenssaetze aus irgendwelchen
Importen inklusive "fremder" Aenderungsstempel sind) man
in den importierten Daten dieses Feld nachgerade freihalten
muesse, wo schliesslich beim Speichern auf jeden Fall ein
neuer Zeitstempel entsteht. Oder dass beim Update in solchen
Faellen durch irgendwelche Tricks die Zeitstempelung und/oder
Datumsvergleiche durch die Bediener abgeklemmt werden sollten.
Fuer mich sind das drei Komplexe, die ziemlich unabhaengig
voneinander sind:
- dass a99 die Datenintegritaet gewaehrleistet
- ob (und wo) ich beim Merge fremde oder eigene Aenderungsstempel
  ueberleben lassen will
- ob (und wo) beim Speichern neue Zeitstempel entstehen



Weitere Beobachtungen:

* gesperrte Datensaetze fuehren beim Update (also beim Einlesen
  der Fremddatei im Modus uxx0) jeweils zu einem leichten Stocken
  der Fortschrittsanzeige, fehlen dann aber ohne weitere Hinweise
  in der bearbeiteten Menge der "Daten in Bearbeitung" (und
  werden wohl auch echt nicht bearbeitet).
  Offensichtlich wird also jeder Satz kurz gesperrt, aber warum?
  Natuerlich ist es nicht schoen, wenn erst beim Speichern auffaellt,
  dass ein Satz gesperrt ist, andererseits kann es Konstellationen
  geben, dass ein Satz tatsaechlich erst spaeter gesperrt wurde,
  insofern ist da auf jeden Fall eine Verarbeitungslogik faellig
  ("Trotzdem speichern?" evtl. bereits eingebaut, habe ich nicht
  ueberprueft).

* Bei "Datei->alle bearbeiteten Daten Speichern" fehlt im Gegensatz
  zu "Datei->Offlinedaten in die Datenbank" ein Fortschrittsbalken.

* Die Boxen "Trotzdem speichern", "Sorry, jemand anderes" etc.
  sollten jeweils die laufende Nummer und die Gesamtgroesse der
  Operation angeben, sonst ist der Bearbeiter im dunkeln, ob
  ihm nicht die Frage zum immer gleichen Datensatz vorgelegt wird
  bzw. ob sich Klicken lohnt.

* Es fehlt ein Abbruch-Button: Aus so einer Schleife mit veralteter
  Ergebnismenge kommt man nur durch tausende von Klicks oder durch
  Abschiessen von a99 via Task-Manager heraus. In letzterem Fall
  bleibt ein Datensatz gesperrt zurueck, das sollte m.E. gar nicht
  sein, zumindest sehe ich keinen Grund, den Satz gesperrt zu
  halten, den der Benutzer eventuell "trotzdem" speichern soll,
  waehrend er noch ueberlegt, was zu tun ist.

* Offcheck.flx strauchelt ueber gesperrte Saetze, behauptet, es faende
  den Primaerschluessel nicht im Register (schreck: aber er ist da)
  und verwirft den Offline-Speicher. Das waere ja ein netter Nebeneffekt,
  damit ein Folgeversuch nicht bereits bearbeitete Saetze trifft, die
  eben durch das Speichern einen neueren Datumsstempel bekommen haben,
  jedoch:

* Es genuegt nicht, mittels Besen die Offline-Datei zu leeren,
  bei meinen Tests gab es stellenweise berechtigt zu alte
  Datumsstempel, "update" hatte sich wohl aus den "zuvor angesehen
  Datensaetze[n]" bedient und dort eine aeltere Version von real
  bereits geupdateten Datensaetzen gefunden. Das ist zwar
  moeglicherweise nur ein Folgefehler des Programmabschusses
  vorher, es bleibt aber ein ungutes Gefuehl darueber, was man
  vorbereitend fuer eine an sich einfache Aktion unternehmen
  muss, um verlaessliche (d.h. es wird wirklich die Datenbank
  manipuliert und nicht laengst vergessene Aufnahmen in irgendwelchen
  Zwischenspeichern) Ergebnisse zu erhalten.
  Andersherum (mir sind die internen Ablaeufe beim "Wechsel" von
  Datensaetzen nicht klar, daher vielleicht die falsche Sprache): sollte
  nicht individuell bei jedem Speichern in den lokalen Versions-
  Aufbewahrungsdateien der entsprechende Vermerk aktualisiert werden,
  damit auch ein Programmabsturz die Inkonsistenzen nicht erhoeht
  (hier hielt a99 ja in der Folgesitzung fruehere Versionsstaende
  von Datensaetzen fuer aktueller als in der Datenbank, obwohl es
  selbst in der Vorgaengersitzung die Saetze aktualisiert gespeichert
  hatte)

* set ti ist lt. xset.rtf "nur avanti", lt. flex.vw aber auch fuer
  a99 verfuegbar?

* flex.vw verschreibt den cstring "ce" als "ue"


viele Gruesse
Thomas Berger