[Allegro] Variablen-Lebensdauer / -gueltigketi beim Index-Lauf

[Thomas Berger]

Lieber Herr Eger,

> als "Primärschlüssel" im Kontext einer Allegro-Datenbank
> verstehe ich den Schlüssel mit folgenden Eigenschaften:
> 
> - ist eindeutig in der Datenbank
> - wird von 'update' verwendet, um das Vorhandensein eines 
>   Datensatzes in der Datenbank zu ermitteln
> - wird im a99 / acon durch 'var p' ausgelesen

Das waere dann der erste der bei derjenigen Sprungmarke,
die ueberhaupt etwas produziert, produzierte Schluessel.


> 
> Unter Kompatibilität im allegro-Kontext verstehe ich
> die Paßfähigkeit bzw. gleichartige Behandlung in allen 
> aktuell verwendbaren Allegro-Komponenten.
> 
> Sie schrieben weiterhin u.a.:
> 
>>>    C3: (in Reihenfolge ihres Auftretens in der ?pi-Datei abgearbeitete
>>>        ak-Zeilen bis zur Produktion des ersten gültigen Schlüssels)
>>
>> bis einschliesslich?
> o.k. bis zur abgeschlossenen Produktion ;-)
> 
>>>    D1: #-@  Primärschlüssel
>>
>> Nein. Das ist wirklich nur Konvention (bzw. fuer die erwaehnte PRESTO-
>> Navigation fest verdrahtet: Hat man aber Daten mit etwa #00 und #09,
>> /muss/ man bei #-@ sogar etwas realisieren, das nicht dem (ersten)
>> Primaerschluessel entspricht.
> 
> Das kollidiert dann aber mit dem Verhalten von cstring p.

Nein, nur mit der Dokumentation auf xcstring.rtf
(soeben noch einmal getestet)



>>>    D2: #-0  Kurztitel
>>
>> Auch nur dann, wenn man auf die Funktionalitaet index -fs Wert legt.
> 
> Warum sollte man das nicht? Es wird standardmäßig im org-Menü 
> angeboten, also muss es auch funktionieren.

Bei einer Anwendung von mir (HANS? Allegro-NRW?) ist mir vor
Jahren aufgefallen, dass es nicht funktioniert (obwohl ich
#-0 und #-/ genutzt habe): Anlaesslich der Initialisierung
habe ich relativ aufwendig per Nachladung Erscheinungsjahr etc.
aus evtl. ueber- oder untergeordneten Saetzen ermittelt und
auch sonst kraeftig normiert, die Indexparameter greifen an
vielen Stellen darauf zurueck, insbesondere fuer Restriktionen-
tabelle und Kurztitelliste.

Damit index -fs und index -ft funktionieren, muesste diese
Initialisierung (mindestens) bei jeder dieser beiden Sprungmarken
erfolgen, im Rahmen regulaerer Indexierung daher (mindestens)
einmal zu viel. Das war es mir nicht Wert (oder gibt es irgend
jemanden, der diese Funktionen in den letzten 15 Jahren einmal
ernsthaft angewandt hat?)


> Es wird klarer:
> 
> Wenn man dafür sorgt, dass folgende Indexparameter-Abschnitte
> "für sich" bleiben (also voneinander unabhängig sind):
> 
> - durch 1. ak-Zeile adressierte Abschnitte
> - #-0
> - #-/
> - alle anderen, durch ak-Zeilen erreichbare Abschnitte
> 
> sollte man auf der sicheren Seite bezüglich der Variablenverwendung 
> sein ...

Wenn man dann noch genauso sorgfaeltig die nicht von ak-Zeilen
angesprungenen Abschnitte #--, #-1 - #-9, #-: #-; und die
Abschnitte fuer die Registermaskerade und den Hilfsabschnitt
behandelt: Auch dort werden Variablen genutzt, die sorgfaeltig
auf Aufschaukeln etc. kontrolliert werden muessen. Sonst kann
es vorkommen, dass das Programm nach 100 Indexzugriffen gerne
abstuerzt, es sei denn, man hat zwischendurch einen beliebigen
Datensatz gespeichert...

Ach ja, und die Interferenzen mit den Anzeigeparametern nicht
vergessen: Alle Parameterdateien muessen Variable *vor* der
Nutzung loeschen, denn nach der Nutzung aufraeumen ist zwar eine
nette Idee (wegen der Data-driven ak-Zeilen insbesondere in
Indexparametern allerdings schwer durchfuehrbar), hilft aber
nicht, wenn zwischendurch eine andere Parameterdatei am Zuge
war und nicht aufgeraeumt hat...



> In Ihrer vorletzten Mail schrieben Sie noch:
> 
>> Die Sprungmarke #-@ ist schon laengst nicht mehr (fuer den Index)
>> verdrahtet, PRESTO hat aber gewisse Navigationsfunktionen daran
>> aufgehaengt. 
> 
> aber: siehe cstring p.
> 
> Diejenigen, die noch Presto benutzen, benötigen die 32bit-index.exe 
> nicht - brauchen also ihre ?pi-Datei nicht anzufassen.

???

Auch "Family/family" war an #-@ gekoppelt, das war die nahtlose
Fortsetzung des PRESTO-Features. Mir scheint das immer noch so
zu sein, auch wenn die Dokumentation das im Unklaren laesst.

[Habe das gerade an einer Datenbank getestet, die #-@ nicht
anspringt und den Primaerschluessel aus #00 nimmt, wobei die
Verknuepfungen jedoch ueber #09 realisiert sind.

Bei #-@ ist folgendes parametriert:


#-@                       Hierarchieschlssel: Nur fuer Presto b/B-Mimik
  folgendes vorbehaltlich spaeterem Umstieg auf w/W
!09 +# e"=" F" " p"|9"      % wenn #09, dann diese als Hierarchie
!84 +#98z b"_" e" " y2 P"*" p"|9"   % wenn #84, dann diese als Hierarchie
!00 +# e"[=]" F" " p"|9"   % wenn uebergeordnet, will PRESTO dies
                            % natuerlich auch wissen. Es ist dann derselbe
                            % Schluessel wie bei #-€.
#+#

Im Schreibfeld von a99 bei angezeigtem Band bringt

x var ""\Family

Eine Ergebnismenge mittels der #00 der Uebergeordneten Aufnahme
und allen Baenden in der korrekten Reihenfolge, ich wuesste nicht,
woher das stammen sollte, wenn nicht aus der Konstruktion bei #-@
]

Mit INDEX16.EXE /index[32].exe hat das alles aber nichts zu
tun, daher verstehe ich Ihre Bemerkung leider nicht.

viele Gruesse
Thomas Berger