F: CAT.API-Problem bei zweistufiger Indexrg. (- at 1+-@2)

[Heinrich Allers]

Einen guten Morgen und Wochenanfang an alle!


                Beim Versuch, eine Datenbank von Version 12.2
(1993) auf V. 14 (1996) zu hieven, und dazu die Standard-CAT.API
(mit 41.490 Bytes, vom 6.9.1996) aus der Braunschweiger Lieferung
zu benutzen, staunte ich nicht schlecht, als ich es im (eigent=
lich Personen vorbehaltenen) Register 1 von Titelstichwörtern
wimmeln sah.

Wichtig ist dabei, daß dies dann der Fall war, wenn ich "uber das
CockPit (Routinen/organisieren ...) reorganisierte. Steuerte ich die
Neuindexierung der Datenbank direkt "uber den einmaligen Start des
Allegro-Programms INDEX, ohne die Optionen - at 1 und - at 2, die dem
zweistufigen (für Datenbanken echter V14-Struktur obligatorischen)
Indexierungsprozeß eigen sind, war alles in Ordnung (will heißen:
die Titelstichwörter blieben brav in Register 3 und verirrten sich
nicht in Register 1).

(Das CockPit macht einen zweistufigen Indexierungsprozeß, mit - at 1
und - at 2, weil es wegen der Parameterangaben f"ur i4, i5 und i6 in
der Indexparameterdatei eine Datenbankstruktur wittert, die eine
ad"aquate - V14-gem"a"se - Reorganisationsprozedur verlangt).

###

Im Rahmen der Untersuchung und Eingrenzung des Problems bin ich
an folgendem Punkt gelangt:

Die aus einem einzigen Datensatz mit einer einzigen Kategorie

#20 aaaa bbbb cccc

bestehende Datenbank wird indexiert mit folgender Indexparameter=
datei CAX.API (Reduktion von CAT.API auf den wesentlichen Kern des
Geschehens):

zl=0
zm=0
ad=0
ag=0
i4=1
i5=_
i6=9
il=220
ic=1
i0=72
|1="1 : Namen von Personen"
|3="3 : Wörter (Titel- und Schlagwörter)"
ak=zz+@
ak=20" "+E
#-E
#uty
!u1
#+#
#-@
#nr dty p"|3" e2 aty e0
#+#
ti


Die Untersuchung erfolgt nat"urlich - ich kann 's nicht lassen,
Werbung f"ur diese Methode zu machen :-)  - mit Testschleifen-
Stapeldatei:

@echo off
:anfang
set -p=
set -d=
rem Aufruf von Festplattenverwaltungssystem:
xx
pause
set -d=c:\allegro\katalog
set -p=c:\allegro
%-p%\index -f70 - at 1 -n0 -m0 -kA -d*%-d%\cax -ecax/%-d% -lGER
cls
echo Anschauen der Datenbank nach 1. Indexierungsschritt - at 1:
pause
%-p%\presto -a3 -d%-d%\cax -n1 -pd-1 -S
%-p%\index -fi1 - at 2 -n0 -m0 -kA -d*%-d%\cax -ecax/%-d% -lGER
cls
echo Anschauen der Datenbank nach 2. Indexierungsschritt - at 2:
pause
%-p%\presto -a3 -d%-d%\cax -n1 -pd-1 -S
%-p%\index -d%-d%\cax -f70 -s0 -v0 -m0 -ecax/%-d% -n1 -h0
cls
echo Anschauen der Datenbank nach Indexierung alter (Pr"a-14-) Art:
pause
%-p%\presto -a3 -d%-d%\cax -n1 -pd-1 -S
goto anfang

###

Das Ergebnis nach dem 1. Indexierungsschritt (mit - at 1):

Register 1 hat keinen Eintrag.
Register 3 hat den Eintrag 'aaaa'.
- Zwangsl"aufig unvollst"andig. 

Das Ergebnis nach dem 2. Indexierungsschritt (mit - at 2):

Register 1 hat die Eintr"age 'aaaa', 'bbbb' und 'cccc'.
Register 3 hat den Eintrag 'aaaa'.
- Falsch!

Das Ergebnis nach Indexierung alter (Pr"a-14-) Art:

Register 1 hat keinen Eintrag.
Register 3 hat die Eintr"age 'aaaa', 'bbbb' und 'cccc'.
- Wie es sich geh"ort!

###

Also, entweder liege ich v"ollig falsch, oder Allegro verheddert
sich hier bei der Reorganisation der recht originellen Verwendung
der Anwendervariablen #uty wegen, die als das das Register
bestimmende Pr"afix eingesetzt und offensichtlich beim zweiten
Indexierungsdurchlauf (mit - at 2) gar nicht mehr besetzt wird und damit
nicht mehr zum Zuge kommt und die Stichw"orter in Register 1 landen
l"a"st.

Aber wenn dem so w"are, wie ich das hier unterstelle: da h"atte doch
vorher schon jemand anders dr"uber stolpern m"ussen!???


... fragt sich, und
gr"u"st zugleich:

Heinrich Allers

Goethe-Institut, M"unchen
heinrich.allers at goethe.de