[Allegro] Update-Dokumentation

[Thomas Berger]

Hallo Herr Fischer,


>> Situation programmieren, ich bevorzuge aber den Weg, in einem
>> vorgeschalteten (srch-)Lauf gezielt die Matchcodes gegen die Datenbank
>> zu testen und auszuwerten, und im Trefferfall die Identnummer aus
>> der Datenbank im Exportergebnis zu hinterlegen (und im mehrere-Treffer-
>> Fall, der ja im Fall allgemeiner Matchcodes keineswegs implizit "verboten"
>> ist, muss ohnehin etwas entschieden werden, z.B. verwerfen dieses
>> Matchcodes
>> und Fortsetzung der Suche mit anderen, oder genauere Analyse des
>> getroffenen
>> Satzes nach sekundaeren Kriterien).
>>
>> Ein anschliessendes Update mit Standard-Primaerschluessel befolgt dann die
>> solcherart bereits fixierte Identifikation ganz exakt.
> 
> Das klingt im Prinzip interessant, nur lande ich so bei srch.exe, für dessen
> Dokumentation leider alles das verschärft zutrifft, was ich an der
> Update-Dokumentation beklagt habe; verschärft, weil ich nicht in den Script-Code
> eines srch.job mit Kommentaren hineinschauen kann (den gibt es auch, ist aber
> wohl eine veraltete Zwischenlösung).
> Schon die einfache(?) Aufgabe, "in einem vorgeschalteten (srch-)Lauf gezielt
> die Matchcodes gegen die Datenbank zu testen" kann ich mit der mir vorliegenden
> Dokumentation nicht lösen.

Nun, es gibt hier nicht die Methode der Wahl:

mit srch.exe (oder acon.exe -j srch.job) koennen Sie ueber die
zugeschaltete Parameterdatei Registerzugriffe durchfuehren und
entsprechend verzweigen und verarbeiten. Guenstigstenfalls
liefert Ihnen also eine einzeilige Erweiterung der i-1.apr
bereits einen Guten-ins-Toepfchen-Filter.

Umgekehrt liefern Ihnen srch.job und vor allem Update.job
das Geruest, Datensaetze aus einer Datei im Dateisystem
einzulesen, mit Information daraus eine /Recherche/ in
der Datenbank zu veranstalten und auf die Ergebnisse
ebenfalls zu reagieren. Und fuer die Weiterverarbeitung
mittels Parameterdatei steht Ihnen dann noch die volle
Exportsprache zur Verfuegung. Hier ist der Weg etwas
steiniger, weil Sie nicht die uebersichtliche i-1.apr als
Ausgangspunkt nehmen muessen, sondern die vielhundertzeiligen
vorhandenen Job-Dateien. Das liegt aber eben daran, dass
diese vielen hundert Zeilen das explizit ausfuehren, was
srch.exe (und das alte Update.exe) implizit machten.
Der Weg ueber acon ist m.E. dann zwingend, wenn einfaches
"Nachschlagen" von (ggfls. umcodierten) Kategorieinhalten
nicht mehr ausreicht. Die Flex-Sprache von a99 kann das
alles im Prinzip auch, hier ist das Protokollieren und
Wegschreiben von Ergebnissen aber normalerweise etwas
kniffliger, und fuer Daten, die noch nicht in der Datenbank
sind, halte ich eine nichtinteraktive Prozedur wie acon auch
sehr gut geeignet.

Eine moegliche Entwicklung koennte sein, das Geruest von
srch.job und update.job in eine Flex-Datei auszulagern,
die von selbstgeschriebenen Flexen eingebunden werden kann:
Bislang passiert das dort nur fuer das Verarbeiten von
Aufrufoptionen etc., aber man koennte auch wie folgt
vorgehen:

Eigenes Unterprogramm bindet ein process-record.job-Include
ein, das folges Interface zur Verfuegung stellt:

- init
- get (next) record
- finish record

Damit kann sich dann Ihr selbstgeschriebener Job ganz
auf das Matchen und Mergen konzentrieren.

viele Gruesse
Thomas Berger