[Allegro] Zweite Datenbank auf, ExFlex, Ergebnis verarbeiten

[Sibylle Koczian]

Lieber Herr Berger,

Thomas Berger schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Liebe Frau Koczian,
> 
> [ich sehe nicht ganz, warum man a99 starten muss, bloss
> um aus einer Datenbank einen Satz zu exportieren, aber sei's
> drum]
>
Von einem Satz habe ich sicher nichts gesagt? Ich brauche im Normalfall 
1300-2000 Sätze, manchmal mehr, und die Volltextsuche geht in manchen 
Einsatzfällen nicht (s. meine zwei Anfragen vom 13.7. und 15.7. zum 
Thema "Volltextsuche, >-Vergleich und Komma im Suchbegriff"). Über das 
Register lassen sich die gesuchten Daten dagegen sehr gut finden.

> 
> 
>>Datenbank Nr. 1 ist offen.
>>Datenbank Nr. 2 wird geöffnet.
>>Aus Datenbank Nr. 2 wird ein Export gemacht (per externem Flex).
>>Das Ergebnis dieses Exports wird in Datenbank Nr. 1 weiter verarbeitet.
>>
>>Mit mehreren Flex-Befehlen müsste das ja so aussehen:
>>
>>variable <A99-Aufruf für Datenbank Nr. 2 zusammenbauen>
>>cAll / CAll
>>flex <externer Flex, produziert output.adt>
>><output.adt weiter verarbeiten>
> 
> 
> das ist insgesamt problematisch: Abgesehen von dem Problem
> mit c[aA]ll, auf das Sie schon gestossen sind: Nur Datenbank
> 2 "weiss", wann sie mit aufstarten fertig ist. Sie koennten
> im aufrufenden Flex in Datenbank 1 natuerlich ein grosszuegiges
> sleep spendieren, aber es wird immer Situationen geben, wo
> das nicht ausreicht. Vorschlag daher, die Aktion fuer
> Datenbank 2 lieber aus deren _start.flx heraus ausloesen zu
> lassen.
> 
Was natürlich voraussetzt, dass Datenbank 2 nie zu anderen Zwecken 
gestartet wird. Oder sie bekommt ad hoc einen speziellen _start.flx - da 
die Suche in Datenbank 2 einen variablen Suchbegriff mitbekommen muss, 
geht es sowieso nicht anders. Die Idee gefällt mir, auf das 
sleep-Problem war ich auch schon gestoßen.

> Aehnlich problematisch ist das warten des urspruenglichen
> Flexes, bis Datenbank 2 eine output.adt produziert hat: Hierfuer
> wuerde sich eher ein externer Flex anieten, d.h. der Flex
> in Datenbank 2 alarmiert einen zusaetzlichen Flex fuer
> Datenbank 1, sobald die Ausgabe abgeschlossen ist.
> 
Also doch Pingpong spielen.
> 
> 
>>Wenn aber mit "call" bzw. "cAll" eine Batchdatei aufgerufen wird, in der
>>sowohl der Aufruf von A99 als auch der Aufruf von Flex.exe enthalten
>>sind, müsste es gehen. Der externe Flex sollte dann mit "STOP" enden,
>>damit Datenbank Nr. 2 wieder geschlossen wird.
> 
> 
> Das Problem der Verfuegbarkeit von output.adt ist auch mit der
> Batchdatei nicht hinreichend geloest, vor allem bei C[aA]ll nicht.
> Aus einem mit c[aA]ll gestarteten Programm hingegen ist es unter Win'9x
> nicht moeglich, weitere Fenster zu oeffnen, wie es das zweite a99
> erfordern wuerde. Auch fuer die Frage, wann das gestartete a99 bereit
> fuer die Verarbeitung eines externen Flexes ist, sollte es irrelevant
> sein woher gestartet bzw. geflext wird, die Zeit ist kritisch, nicht
> der Weg.
> 

Glücklicherweise muss mich Win'9x nicht interessieren, das Ganze ist nur 
hier fürs Haus bestimmt.

Eigentlich würde ich viel lieber einen Avanti-Client schreiben, der das 
Ganze in einem Aufwasch erledigt, mit einem Minimum an Flex-Sprache 
(auch wenn der Rest leider Perl sein müsste und nicht Python). Aber da 
kriege ich weder ein Update auf Probe noch ein Update mit 
Dublettenliste. Und die Kombination von Avanti-Export und 
Classico-Update scheitert daran, dass Avanti nicht (mehr) ins 
Internformat exportiert, Classico dies aber braucht. Noch ein Import 
dazwischen bläst die Geschichte unnötig auf.

Schöne Grüße,
Koczian

-- 
Dr. Sibylle Koczian
Universitaetsbibliothek, Abt. Naturwiss.
D-86135 Augsburg

Tel.: (0821) 598-2400, Fax : (0821) 598-2410
e-mail : Sibylle.Koczian at Bibliothek.Uni-Augsburg.DE