AW: AW: AW: [Allegro] Avanti update, Nachbesserung

[Thomas Fischer]

Hallo Herr Eversberg,

> > Erstens:
> > Ich pflege etwa 20 Allegro-Datenbanken, fast alle mit dem 
> > Konfigurationsbuchstaben g, allerdings mit diversen 
> Variationen in den
> > Datenbanken: Ascii oder UTF-8 Zeichensatz (neuerdings auch ein 
> > OSTWEST-Font), verschiedene Teilfelder etc.  ...
> Nicht für alle diese Komplikationen ist allegro verantwortlich.

Nein, natürlich nicht, aber das sind di Bedingungen, unter denen ich Allegro
betreibe.
Mein Ziel ist nur, das alles nicht noch zusätzlich zu verkomplizieren

> > Zweitens:
> > Dass es trotz mehrfacher Versuche nicht gelungen ist, das 
> > avanti-System dazu zu bringen, sich so zu verhalten, wie es in der 
> > Dokumentation beschrieben ist,
> Es verhält sich so, aber die Beschreibung ist zugegeben 
> manchmal mißverständlich, ich muß da nochmal ran. Allerdinge 
> beantworten Sie nicht selten meine Fragen ebenfalls miß- oder 
> unverständlich, wenn denn überhaupt vollständig. So redet man 
> permanent aneinander vorbei!

Das ist offenbar schwieriger als gedacht.
Ich hatte gehofft, durch Benutzung der Demo-Datenbank und eines zusätzlichen
Avanti-Verzeichnisses meine Testergebnisse nachvollziehbar zu machen. Diese
Installation kam mir einfach genug vor, dass jeder (insbesondere Sie) sie
nachbauen und damit Test durchführen konnte.
Mich würde schon interessieren, ob jemand mit dieser Konstellation zu
anderen Ergebnissen kommt als ich.

Allerdings muss ich aus den ausbleibenden Reaktionen von anderer Seite auch
schließen, dass außer mir wohl kaum jemand den "virtuellen Aufrufpfad" (so
intensiv) benutzt, sonst müsste es doch aufgefallen sein, dass der mit der
neuen Version nicht mehr wie früher funktioniert.

> Hier nochmal klipp und klar:
> 
> Wenn eine Datei gesucht wird, dann geschieht das so:
> 
> 1. DbDir (ergibt sich aus avanti.con)
> 
> 2. Direkt (Verzeichnis, wo acon läuft.)
>     Wird acon z.B. auf  /usr/fischer so gestartet:  /allegro/acon
>     dann ist /usr/fischer das Verz., wo gesucht wird, NICHT dasjenige,
>     wo die Datei  acon  liegt, also /allegro.

Das ist mit dem Verzeichnis identisch, das bei einer Windows-Verknüpfung
unter "Ausführen in:" angegeben wird?

> 3. Verzeichnis, das in der &-Zeile angegeben ist
>     Wenn diese nicht gesetzt ist, DANN dasjenige, wo acon LIEGT,
>     hier /allegro  (und nicht das, von wo es gestartet wurde -> 2.)

Das kann ich so nicht bestätigen, auch bei angegebener &-Zeile wird im
Programmverzeichnis gesucht.
Allerdings wird auch bei angegebener &-Zeile in dem entsprechenden
Verzeichnis keine der in die *.xpi-Datei eingebundenen Dateien gefunden, im
Programmverzeichnis aber wohl.
Insofern ist mein Eindruck, dass das Programmverzeichnis als viertes
Verzeichnis zu berücksichtigen ist bzw. die von Ihnen angegebene Ersetzung
des Programmverzeichnisses durch den Aufrufpfad eben nicht stattfindet.

> NUR für die CFG und diejenigen Parameter, die zum Index 
> gehören, also .API und darin nachgeladene .APTs, empfehle 
> ich, sie ALLE bei der Datenbank zu halten, also auf 1., die 
> anderen nach Zweckmäßigkeit auf 2.
> und 3.

Heißt das, dass für diese Dateien die oben genannte Reihenfolge nicht gilt?
Und wenn nicht, welche gilt dann?
Ich benutze neben Übersetzungstabelle (o.*pt, iu.*pt) noch verschiedene
Indexparameter, die als Tabelle index.gpt von diversen Indexparameterdateien
nachgeladen werden, diese müssten also dann bei den einzelnen Datenbank
liegen? Oder können sie auch im Programmverzeichnis benutzt werden? (Das das
mit dem &-Verzeichnis derzeit nicht geht war ja de Ausgangspunkt dieses
Austauschs.) 

> Was daran noch obskur scheint oder nicht stimmig, werden wir, 
> sowie es nachvollziehbar ist, bereinigen oder die 
> Beschreibung weiter präzisieren und dann letztendlich in die 
> offiziellen Doku übernehmen, damit auf dem Felde endlich Ruhe ist.

Ich hoffe, dass sich in diesem Prozess vielleicht doch noch die eine oder
andere Lösung findet.

> > lässt mich zunehmend daran zweifeln, dass die 
> Software-Entwicklung das 
> > System noch unter Kontrolle hat.
> > 
> Natürlich erschwert so etwas auch uns die produktive Zusammenarbeit.
> Sine ira et studio können Sie doch nur die Konsequenz ziehen, 
> sich ein anderes System zu suchen.

Da nerve ich doch lieber die Entwicklungsabteilung als 20 Datenbanken unter
zwei Betriebssystem zu migrieren...

Mit freundlichen Grüßen
Thomas Fischer