[Allegro] expi.inc

[Holger Becker]

Liebe Liste,
ich habe ein völlig undurchschaubares Problem mit expi.inc. Wenn ich
versuche, unsere Druckaufbereitung in flex zu realisieren, bekomme ich
manchmal eine seltsame Verdoppelung der Datensätze im letzten
Aufbereitungsschritt. Zur Erklärung:

Wir haben einen vierstufigen Aufbau:

uuu.alg (wird aus der akt. Ergebnismenge erzeugt)
-> Sortierschlüssel erzeugen
u1.alg
-> Sortieren
s1.alg
-> Sortierschlüssel weg
s2.alg
-> Druckaufbereitung
liste

Diese Datei wird dann umbenannt in liste.rtf und in Word eingelesen, mit
einem Makro bearbeitet und gespeichert.

Jetzt schreibe ich mir einen Flex "print.flx", in den expi.inc
eingebunden wird, siehe http://www.allegro-c.de/bluechyp/sort.htm#tex,
unter Anh.

Manchmal bekomme ich durch diesen Mechanismus die richtigen Ergebnisse,
aber manchmal wird auch im letzten Schritt, an dem die expi.inc
beteiligt ist, die Größe von "liste" ungefähr verzehnfacht, einige
Datensätze werden fünf Mal hintereinander eingetragen, andere bis zu 17
Mal.

Hier der dazugehörige Code (ist aber auch im Anhang in der Datei
print.flx zu sehen):

var "-d s2.alg -E liste -e print1"
perf expi
if Z<1 mes
end

Ich kann überhaupt nicht nachvollziehen, was da falsch läuft, denn
vorher laufen schon zwei Aufbereitungsschritte nach dem selben Schema
ab. Ich habe mes-Befehle in die expi.inc eingefügt, um zu sehen, ob der
loop zu oft durchläuft -- das tut er nicht. Es werden einfach nur zu oft
hintereinander die Datensätze eingefügt. Ich habe sogar versuchsweise
alles aus der expi.inc gelöscht, was nicht angesprungen werden soll,
aber es passiert trotzdem.

Das große Problem ist, dass es manchmal klappt und manchmal nicht. Das
einzige, was ist rekonstuieren konnte, war, dass es beim ersten Starten
eine Ergebnismenge durch Aufruf von print.flx (hier in abgespeckter Form
angehängt) eine Datei liste.rtf erzeugt, die 230 kb groß ist, beim
zweiten Mal "X print" nur noch 212 kb und ab da bei jedem weiteren
Aufruf 19 kb, was die richtige größe ist (knapp größer als die s2.alg,
aus der sie erzeugt wird). Das passiert auch mit der beigefügten s2.alg
und der abgespeckten print.flx, in der keine neue Ergebnismenge gebildet
wird, sondern nur meine s2.alg weiterverarbeitet wird.

Ich bin verwirrt und nach Tagen des Testens nun auf Ihre Hilfe
angewiesen. Ich hänge alle relevanten Dateien als zip-Archiv an diese
Mail an. Ich habe die störenden Teile auskommentiert, es geht nur um den
letzten Schritt, die Dateien, die vorher entstehen, sind alle gleich
groß und enthalten nur eine Version der sechs Datensätze (wie die
enthaltene s2.alg auch). Es wird davon ausgegangen, dass s2.alg im
Startverzeichnis (lokal), wo auch die anderen Dateien hingeschrieben
werden.

Es wäre mir schon geholfen, wenn jemand bestätigen könnte, dass das auf
anderen Systemen auch so passiert.

Vielen Dank und viele Grüße aus Marburg,

Holger Becker

-- Holger Becker Wissenschaftlicher Mitarbeiter am Informationszentrum
für Fremdsprachenforschung (IFS) Telefon: +49 (0)6421/28-23802; Fax:
-25710; E-Mail: beckerho at staff.uni-marburg.de; Web:
http://www.staff.uni-marburg.de/~beckerho; Hans-Meerwein-Straße, 35032
Marburg, Deutschland
-- 
Holger Becker
Wissenschaftlicher Mitarbeiter am Informationszentrum für
Fremdsprachenforschung (IFS)
Telefon: +49 (0)6421/28-23802; Fax: -25710; E-Mail:
beckerho at staff.uni-marburg.de; Web:
http://www.staff.uni-marburg.de/~beckerho;
Hans-Meerwein-Straße, 35032 Marburg, Deutschland
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : liste.zip
Dateityp    : application/zip
Dateigröße  : 8471 bytes
Beschreibung: nicht verfügbar
URL         : <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20070806/03b2bd0c/attachment.zip>