Seltsame Abh"angigkeit bei update.exe

[Thomas Berger]

Lieber Herr Allers,

> Das Problem ist also nicht Update oder das Nachladen, sondern
> Ihre Erwartungen an #fna. Ich erinnere mich nicht genau, aber
> seinerzeit hat B.E. bei der Zugaenglichmachung von #fna in
> den Indexparameterdateien davor gewarnt. Anscheinend ist
> es so, dass #fna fuer den Primaerschluessel tabu ist, das
> scheint mir auch sehr sinnvoll so.

Ich habe folgendes gefunden:

>>>
Verlautbarung 100 der Entwicklungsabteilung                       
19971103
-------------------------------------------

INDEX : Sonderkategorien #fna und #nr jetzt moeglich
----------------------------------------------------

Verschiedene Male war von verschiedenen Anwendern gewuenscht worden,
Schluessel aus den Dateinamen oder -nummern bilden zu koennen, oder auch
aus den internen Satznummern.
Dem stand entgegen, dass INDEX die Sonderkategorien #fna (file name)
und #nr  (record number) nicht bilden konnte. D.h. in Indexparametern
konnte man sie nicht verwenden. (#fna funktionierte allerdings in PRESTO
und UPDATE.)
Das war nicht ohne Grund so: es ist aus der Sicht der Datenbanktheorie
fragwuerdig, Zugriffsschluessel zu bilden aus Elementen, die gar nicht
im
Datensatz selbst vorkommen. (Z.B. #dt sollte man wohl keinesfalls
verwenden,
obwohl DAS schon immer funktioniert haette; aber wer kaeme auf die
Idee.)

Bei gewissen Anwendungen gab es aber triftige Gruende, solche Elemente,
insbesondere die Dateinummer, entgegen der reinen Lehre doch als
Register-
eintraege zu verwenden. Andernfalls haette man umstaendliche
Hilfskonstruk-
tionen machen muessen, um gewisse Konzepte zu realisieren.
Nun war es zwar nicht ganz trivial, aber auch nicht ausserordentlich
schwierig, deshalb wurde INDEX jetzt mit der Faehigkeit ausgestattet,
auch die Sonderkategorien #fna und #nr bilden zu koennen.
(Bei PRESTO war es so, dass nur #nr in den Indexparametern nicht
funktionierte. Das wurde ebenfalls eingebaut. Wir nehmen aber an, dass
#nr fuer die Indexierung wohl kaum genutzt werden wird. Ueber die
interne
Satznummer kann man schliesslich, am Index vorbei, mit dem Express-
zugriff zugreifen.)
Empfohlen wird es nicht, aber fuer Experten, die wissen, was sie tun und
warum, faellt damit eine manchmal laestige Einschraenkung weg.

INDEX.LZH und PRESTO.LZH auf ac15/prog wurden erneuert.

Das Handbuch wird zum Glueck hierdurch nicht schon wieder
aktualisierungs-
beduerftig: es steht gar nicht drin, dass #fna und #nr in INDEX nicht
funktionieren. Also STIMMT das Handbuch jetzt endlich.

[...]
<<<

D.h., eigentlich sollte es ohne Einschraenkung funktionieren und
angeblich hat es bei UPDATE sowieso immer funktioniert. An Ihrem
Beispiel kann man jedoch beobachten, dass #fna "normalerweise"
sowohl bei UPDATE als auch INDEX im Primaerabschnitt nicht funktioniert
(und auch PRESTO liefert mit Ihren Beispieldaten Schluessel,
die kein #fna "kennen", die undokumentierte Sonderkategorie #fn 
hingegen wird beruecksichtigt: Moeglicherweise verhalten sich
#fn und #fna wie #nr und #nra zueinander).

Fuer UPDATE kann ich mir allerdings absolut nicht vorstellen,
wie es funktionieren koennen sollte: Der Satz wohnt in einer
Grunddatei und UPDATE bildet den Primaerschluessel, um zu testen,
ob der Datensatz in der Datenbank vorhanden ist. Dafuer muss
UPDATE aus den Informationen in der Grunddatei jedoch die Dateinummer 
des Datensatzes in der Datenbank berechnen, was insbesondere
voraussetzt, dass der Datensatz in der Zieldatenbank vorhanden
sein muss!

viele Gruesse
Thomas Berger