AW: avanti-cl: Programmdatei erneuert

Mi Mai 8 10:27:22 CEST 2002

Lieber Herr Bachschneider,

> Oder man schließt die Sitzung und öffnet eine zu einem anderen Avanti.
> Mit anderen Worten: Ein gestarteter Avanti bedient immer genau nur eine
> Datenbank.

Hier haben wir evtl. nur ein Sprachproblem: Das, was Sie hier
"Avanti" nennen, kenne ich als procav (oder meinethalben avanti-cl).
Fuer mich ist "Avanti" aber immer noch der genuine Server,
exakter also avntserv oder avanti-xy.

> so könnte man die avanti-cl´s schon mit .CFG und .API initialisieren.
> Es wären also zwei oder drei Änderungen am Avanti-cl nötig:
> 1) Bearbeitet Job nach AVANTI:EOJ ohne sich selbst zu beenden
> 2) Läßt sich mit Datenbankangabe initialisieren
> 3) Terminiert sich selbst bei EOF, oder optional nach einem Timeout

laengerfristig wuerde man hier dann auch etwas mit XML bauen
(aber besser SOAP-konform):

> Die Initialisierung ließe sich ja mit einem Job bewerkstelligen, sofern
> Avanti .CFG und .API
> nur dann wieder freigibt wenn ein Folgejob eine andere Datenbank anfordert.

Daran hatte ich nicht unbedingt gedacht. .APR's und .APT's
muss procav ja ohnehin mehrfach laden koennen (werden die
dann aufeinandergestapelt oder immer neu gelesen?).
Ich koennte damit leben, dass ein *fuer eine Datenbank
initialisiertes* procav tatsaechlich nur noch diese
eine Datebank "kann" und im Zweifelsfall irgendwann
beendet werden muss (Man will ja auch eine Balance finden
zwischen neuen Anfragen und der Optimierung von "Sitzungen",
sonst geraet man in die Falle, aus procav wieder einen
eigenen "Server" zu machen, so dass das Tandem avanti-w
und procav ploetzlich eine merkwuerdige Art von Doppel-
Server wird).

> Und wenn man es recht bedenkt, war es immer schon Quatsch die
> Datenbankangabe im Schlußstring
> zu führen und nicht als set DB=

Aber ja, vor allem wenn man bedenkt, dass avanti-w
das garnicht kann: Die Kommunikation ist so mies, dass
man durch geeignete Fragmentierung der Uebertragung
(also clientseitig unbuffered output) die schoensten
Fehlermeldungen bekommt, wenn der Job vor der Abschlusszeile
und auch wirklich getrennt von ihr bei avanti ankommt...
Als Extremfall koennen Sie einmal versuchen, ein
telnet localhost:4949
zu machen: Sie fliegen sofort raus, weil avanti losrappelt,
auch wenn noch kein einziges Zeichen des Jobs uebertragen
worden ist...

> Ihre Vorschläge führen auch aus der Verlegenheit heraus, eine DLL oder
> Sprachbindung haben zu müssen.

Nicht unbedingt. Herr Hoeppner hat vor zwei Jahren ja einmal
seine Experimente zur Office-Integration (->Active-X control)
gezeigt. Die waren avanti-basierend, wenn ich mich recht
entsinne, koennten aber eigentlich auch "lokal" realisiert
werden. Schoen waere ein avanti-artiges, gemeinsames Interface,
so wie es etwa auch Access darstellt: Die Datenbank kann
lokal sein und direktem Zugriff unterliegen, es kann aber
auch ueber tcp/ip ein Server drangebunden sein.