[Allegro] acon: if Del ... nach fetch record

[Thomas Berger]

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

Lieber Herr Eversberg,

>>>> Vor allem letzteres ist ein Problem, weil unzaehlige Legacy-Exporte
>>>> darauf eingestellt sind, die interne Satznummer (.ald) bzw. die
>>>> fortlaufende
>>>> Position in der Eingangsdatei (.alg) als #nr zu exportieren
>>> Das bleibt so!
>>
>> Dann kann man aber jeden Versuch aufgeben, mit SRCH oder a99 genutzte
>> Parameterdateien (fuer Exporte) mit acon zu nutzen: Wir haben damit
>> nicht nur ein Schisma zwischen FLEX und JOB, sondern auch eines
>> zwischen Exportparameterdateien "fuer a99" und "fuer acon". Wollen
>> Sie das wirklich?
>>
> Jetzt dramatisieren Sie nicht! Wann ist es je sinnvoll, die interne
> Satznummer zu exportieren? Das Feld #nr wird oft als Platzhalter
> verwendet, wenn man eine stets existierende Kategorie braucht,
> aber das kann man schadlos beibehalten, das ist kein Problem.

Das ist klar, aber darauf wollte ich nicht hinaus.

Aber bei "mehrstufigen Exporten", also Export gefolgt von Sortierphasen
und weiteren Exporten ist #nr (in s-0.apr etwa als #99z weitergereicht)
ein ganz zentrales Mittel, um - man denke an ein Register zu einem
Export - einerseits Eindeutigkeit zu erzwingen ("Gruppierung" zu erzeugen
im Datenbankjargon): Identische Datensaetze sollen nicht doppelt im
Hauptteil auftreten, Identische Schluessel zu ein und demselben Datensatz
sollen nicht doppelt im Register erscheinen, umgekehrt sollen nicht
identische Datensaetze je einen Eintrag im Hauptteil bekommen und identische
Schluessel zu verschiedenen Saetzen einen Registereintrag (vgl. alpha*.apr:
das sind moeglicherweise Seitenzahlen, fuer "Textnummern" ist das aber auch
denkbar)

D.h. gerade fuer komplexe, selbstgeschriebene Parameterdateien (Bibliographien,
alte Neuerwerbungslisten) ist es zentral, dass #nr folgendes enthaelt:
- - beim Durchsuchen von .ald-Dateien die interne Satznummer
- - beim Durchsuchen von .alg-Dateien die fortlaufende Nummer in dieser Datei


>> und wie merke ich, was acon merkt? Ich meine, wenn erst mal eine
>> verunfallte cat_1.ald.txt in Bearbeitung ist, ist doch nicht
>> unbedingt kanonisch, ob das jetzt .ALD oder .ALG ist.
>>
> Für die richtigen Dateitypen sind Sie schon selber verantwortlich,
> acon, ob intern oder per Job, kann es nicht zuverlässig selber
> feststellen.
> 
>> Also, ich finde acon koennte sich die Muehe machen, die ersten Bytes
>> der Datei zu analysieren und dann zu wissen, wie die zu verarbeiten
>> ist (wobei der Unterschied zwischen .log und .ald vermutlich schwer
>> herauszubekommen ist). Oder ich erledige die Analyse im Job und
>> oeffne die Datei anschliessend erneut: Dann aber soll acon so
>> vorgehen, wie ich es ihm sage(n koennen will).
>>
> Nein, der Dateityp muß stimmen. WinWord streicht auch die Segel,
> wenn Sie ihm eine  brief.doc.txt  vorwerfen. Es versagt sogar,
> wenn es eine .rtf kriegt ohne '}' am Ende! So empfindlich ist acon nicht.

Grrr. Fuer RTF gibt es immerhin eine Spezifikation. Hier aber muesste
nur eine der folgenden drei Bedingungen realisiert werden, wenn nicht,
ist Scheitern in manchen Faellen vorprogrammiert:

a) acon laesst sich vom Job sagen, welcher Dateityp es ist

b) der Job kann acon fragen, nach welchem Paradigma die aktuelle Datei
   verarbeitet wird (nachdem Sie aber angedeutet haben, wie naiv acon
   in Wirklichkeit vorgeht, bin ich mir nicht sicher, ob das viel hilft:
   Immerhin laesst sich dann besser nachvollziehen, warum acon scheitert)

c) Sie dokumentieren absolut exakt den Erkennungsmechanismus von acon,
   so dass man den im Job 100% identisch nachprogrammieren kann.

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

iJwEAQECAAYFAkwYiG4ACgkQYhMlmJ6W47N4GQP/ROSwwclZ00zOIF/xHDr+cFfV
Rf2GFlSGkWBqBspQJkk7hjI81lqPXS7G2iO3FNTfIwk/e5mkKHK2+Bkvj762hw82
lzVCkx3UjsUgGjOg63qVnK5W2/bHDaTclbJzMQzB2YFj5j4E+HI4bO1XkYsz4Jyf
PpaD3TfhHrwP0qEbe+Q=
=ariT
-----END PGP SIGNATURE-----