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

[Bernhard Eversberg]

Thomas Berger schrieb:

>>> 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.

> 
> 
> 
> 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.

B.E.