Index

[Grieser, Wolfgang]

Liebe Kolleginnen und Kollegen,
unser Problem taucht bei hierarchischen Verknüpfungen auf. Gibt es einen
Untersatz #01, so werden #74 und #75 nicht im Index 6 angezeigt. Löscht man
#01. dann werden die Felder angezeigt. Das kann man mit einem völlig simplen
Satz demonstrieren. Eigentlich müssten andere die gleichen Erfahrungen
machen. Im Moment besteht für dieses Problem bei uns kein Änderungsbedarf.
Gruss
Wolfgang Grieser

> -----Original Message-----
> From:	Thomas Berger [SMTP:ThB at gymel.com]
> Sent:	Friday, July 06, 2001 5:04 PM
> To:	Diskussionsliste Allegro-C
> Subject:	Re: Index
> 
> Lieber Herr Eger,
> 
> > Aehnliche Effekte hatte ich auch in der V21:
> > ------------------------------------------------------------------
> > cat.api aus Demo2-Verzeichnis: ("Version": 31.05.2001/Laenge:88910)
> > .
> > #-N
> > .
> > .
> > .
> > #uty
> > !u1 u e"_" f" /(<)+-" F"* " e69       die Zeichen " /()<+-" am Anfang
> wegnehmen
> > .     ^^^^
> > .
> > .
> > .
> > #-D   Koerperschaften (#6.) werden so behandelt:
> > #u1 +- i2,8 e0     #68 nicht!
> > #ch +#6n5 i2,n e0    #6n
> > #ch +#6n5 i2,u e0    #6u
> > !u1 u e"_" p"|2"    (auch hier evtl. Ansetzungsform hinter " = ")
> > #+#   ^^^^
> > -----------------------------------------------------------------
> > 
> > Die Befehle e"_" bewirken, dass die Anweisung mit der Index-Exe NICHT,
> > mit PRESTO.EXE dagegen ausgeführt werden, wenn sich in der betreffenden
> > Kategorie eine Stammsatzverweis (_xxxx) befindet.
> > 
> > Auswirkung: Nach manueller Eingabe sind die Registereintraege vorhanden,
> > nach Neuindizierung sind sie weg (alle anderen Stammsatzersetzungen,
> > die keine derartige "Behandlung" erfahren, funktionieren, ich hab'
> > auch nur EINE Konfiguration/*.api ...
> 
> Vorsicht, das Verhalten ist diffiziler:
> 
> PRESTO kann die Stammsatzreferenz immer aufloesen, d.h. es sieht
> den "_" nie.
> 
> Bei INDEX haengt es davon ab, ob Sie ein- oder zweistufig indexieren,
> wenn letzteres, ob die benoetigten Ersetzungsschluessel auch wirklich
> in der ersten Stufe gebildet worden sind (#8na-Kuerzel z.B. nicht).
> Wenn alles sauber eingestellt ist, werden die Ersetzungsschluessel
> im ersten Durchlauf gebildet, im zweiten Durchlauf sind sie vorhanden
> und INDEX sieht analog PRESTO nur noch die ersetzten Ansetzungen
> ohne "_". Dazu muss man aber ein neueres Cockpit benutzen und die
> Funktionen aus dem Menue Routinen / organisieren.
> 
> Wenn alles nicht optimal eingestellt ist oder bewusst (etwa uebers
> Menue "Funktionen") einstufig indexiert wird, liegen beim Abarbeiten
> der entprechenden Abschnitte in der .API die Informationen in den
> Kategorien noch in bislang nicht ersetzter Form "_..." vor und
> dann wird unterdrueckt. Die von Herrn Eversberg vorgeschlagene
> Korrektur (e"_" wegnehmen) fuehrt dazu, dass "_xyz" zunaechst
> im Register steht und nach Indexierung und Qrix (im "2nd run")
> noch einmal umgesetzt wird (was allerdings nur funktioniert,
> wenn die Ersetzungsschluessel nur aus Kleinbuchstaben und Ziffern
> gebildet werden, also auch keine Pruefziffern "X" haben).
> 
> Herr Grieser hat leider nicht verraten, ob seine #74er und #75er
> mit (selbstgeschaffenen) Stamsatztypen gebildet werden. Wenn nein,
> ist dies hier alles fuer sein Problem irrelevant. Andererseits
> muss er irgendwelche Nicht-Standard-Parameter oder Nicht-Standard-
> Daten haben, sonst haette jemand anderes auch sein Problem...
> 
>  
> > Welchen Zweck haben diese Anweisungen? Soll damit wirklich die
> Ausfuehrung
> > einer Stammsatzersetzung unterdrueckt werden? Wenn ja, dann verhaelt
> sich
> > PRESTO nicht richtig, andernfalls macht INDEX Fehler....
> 
> Die Bedeutung dieses Befehls liegt vermutlich in importierten ZDB-
> Daten, wo die MAB1 -> $A-Schnittstelle die GKD-Nummer nach " _"
> an die Textform der Koerperschaft setzte, zumindest in #60 und
> aehnlichem. Moeglicherweise auch in Titelkategorien hinter zu
> ergaenzende Urheber.
> 
> viele Gruesse
> Thomas Berger