[Fwd: [Allegro] Update updatet nicht]

[Thomas Berger]

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

Lieber Herr Eversberg,

auf die unten angehaengte Mail antworteten Sie, dass Sie sich nach dem
Fest (ich verstand: Ostern) drum kuemmern wollten. Inzwischen hatte ich
die Angelegenheit voellig vergessen und bin am Wochenende erenut auf
dasselbe Problem gestossen, das Fehlerbild war etwas subtiler:

Update erzaehlt etwas von ersetzten Saetzen, die Log-Datei verzeichnet
die geanderte Version, weil die Datenbank aus Performance-Gruenden
rudimentaer (index - at 1) indexiert war, gab es keine direkten Hinweise
darauf, dass eigentlich nichts passierte. Konkreter: Es wurden etwa
20% der Saetze aktualisiert, 80% nicht. Und zwar stabil, d.h. das
Update auf diese 80% eingeschraenkt lieferte 100% Nichtstun, erkennbar
v.a. daran, dass die .ald-Datei einen alten Zeitstempel behielt,
waerend .tbl, .log und .adx immer neuer wurden.
Reproduziert nun auch mit Update.exe v29.6 (andere bis auf die
in der Original-Mail erwaehnten nicht ausprobiert) sowie diversen
Setzungen von -fm beim Aufruf.

Mein Verdacht hat sich ansonsten erhaertet: Wenn ich den GM-Abschnitt
weniger Komplex gestalte, d.h. alle Nachladeoperationen in den
Hauptabschnitten der Paramterdatei ausfuehre und den GM-Abschnitt
ausschliesslich zum loeschen bzw. Ergaenzen vorher bestimmter
Kategorien nutze, funktioniert die Angelegenheit.

Es koennte also wirklich sein, dass (bei Update) Nachladen im
GM-Abschnitt nicht funktioniert. Der Zustand, dass in der Datenbank
in der Log-Datei etwas protokolliert wird, das in der Datenbank nicht
stattfindet, ist aber nicht haltbar und es sollte generell
geklaert werden, in welchen Siutationen das Phaenomen auftreten
kann und was stattdessen passieren sollte.

viele Gruesse
Thomas Berger



- -------- Original Message --------
Subject: [Allegro] Update updatet nicht
Date: Thu, 09 Apr 2009 13:10:11 +0200
From: Thomas Berger <ThB at Gymel.com>
Reply-To: Allegro-C Diskussionsliste <allegro at biblio.tu-bs.de>
Organization: Gymel.com
To: Allegro-C Diskussionsliste <allegro at biblio.tu-bs.de>

Lieber Herr Eversberg, liebe Liste,

ich will Datensaetze live veraendern, bin aber zu faul,
PRESTO oder a99 dafuer zu starten, daher exportiere ich
sie mit i-1.apr in eine .alg-Datei und mische die dann
mit UPDATE ein, dabei ist eine Parameterdatei zugeschaltet,
die die globale Manipulation ausfuehrt:

%-P%\update -fm30 -n99 -ufoobar.alg -eu-foobar/foobar.log -m0 -v0

Dabei nun folgendes Phaenomen: Am Schirm laufen die Saetze durch
(jeweils mit unterschidlichen, plausiblen "xxx Schluessel veraendert",
die Protokolldatei foobar.log enthaelt die Meldungen, die bei der Aktivitaet
ausgegeben werden, Im Datenverzeichnis werden dbn.log und dbn.adx konsistent
aktualisiert, JEDOCH: die .ald-Dateien sind unveraendert!

(getestet mit update.exe v28.8 vom letzten Sommer und dem aktuellen von V29.3,
benutzte .CFG setzt keine Datumsstempel. Byteweiser Vergleich des
Datenverzeichnisses vorher und nachher zeigt keine Aenderung in irgendwelchen
.ALD-Dateien)

Gleiches Phaenomen bei -fm31, -fm40, -fm41

Ist die Ursache eine Selbstueberlistung des Schalter -fm3x (GM-Abschnitt
wird ausgefuehrt, nachdem intern schon unwiederruflich beschlossen wurde,
dass die Datenbank nicht zu aktualisieren ist, aber warum landet es dann
im Log und im Index)?

Oder liegt das Problem in der speziellen Globalen Manipulation
(<hint> es erfolgt eine (erfolgreiche) Nachladung |92 </hint>)?

viele Gruesse
Thomas Berger



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

iQCVAwUBSlJR82ITJZieluOzAQLVDgP9GW+YuoEGE+gyAIEzTHMiH0KWprjZnObE
Q4zr5PaLowoexdrKRlYaaOb6mjkiv7j3jeTt5QbiJrDivGyS3XbUc/+RpNEWH7hp
66o/PQn7D7a/K+lB4SUOaTZQAx2WJ0D85RPWspJqohkyQ9imkjFtbFHBX7Oe3ZXO
Z/LdKpduMbU=
=IzYK
-----END PGP SIGNATURE-----
-------------- nächster Teil --------------
Ein eingebundener Text mit undefiniertem Zeichensatz wurde abgetrennt.
Name: Attached Message Part
URL: <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20090706/c2b999b5/attachment.ksh>