Updatefragen (war AW: [Allegro] V32.4 und Indexparameteraufruf)

[Fischer, Thomas]

Hallo Herr Berger,

schönen Dank für die Antwort.

> > Bei einem ersten Test mit -eparam/datei im Aufruf von update bekomme ich in datei
> Einträge der Art:
> >
> > === neuer Satz ===
> > #002 117712310  #002A00172332zZKA       #004 20120418/19:34:47
> #004N199701241a #004Z20120418/19:34:47  #005 p  #007Z201204071a #800
> Herrmann, Aloys    #805 Mathematiker       #806gm  #806nXA-DE      #808 1930w
> #870 Köthen (Wirkungsort)       #
> > === vorhandener Satz ===
> > #002 117712310  #003 pg11771231 #004 20090427/16:32:33  #005 prd        #007
> 20090720/16:05:37 hsd      #026 dm #800 Herrmann, Aloys    #805 Mathematiker
> #806gm  #806oXA-DE      #807 Köthen     #808 1930w      #809 1935w      #
> >
> > Das ist zwar auch instruktiv, aber nicht das was ich brauche: Ich möchte die
> > *nicht gefundenen* Datensätze in einer Datei sammeln und mit einem neuen
> > Primärschlüssel mit meiner Datenbank vergleichen.
>
> die "nicht gefundenen" waeren ja Neusaetze und wuerden als solche Protokolliert.
> Dann sind Sie natuerlich schon in der Datenbank drin, wenn Sie "datei"
> auswerten...

Ich hätte vielleicht erwähnen sollen, dass ich update mit der Funktion -fm40 laufen lasse, nicht gefundene Datensätze also zurückgewiesen werden.

> Moeglicherweise suchen Sie die Funktionalitaet von "update -fc" ?

Das wäre eine mögliche Alternative, nur muss ich dann die Datei zweimal durchlaufen lassen.
Ich hatte gehofft, dass das auf einmal ginge. Sagen Sie, dass das mit dem alten Update auch nicht ging?
Und sehe ich das Recht, das es bei dem A99-Update kein Äquivalent zu -fc gibt?
>
> > Gibt es diese Möglichkeit nicht bzw. muss ich die selber an der Stelle in
> > update.job einprogrammieren, wo der Primärschlüsselvergleich erfolglos blieb
> > (siehe auch meine obige Frage)?
>
> fuer "und mit einem neuen Primaerschluessel ... vergleichen" hoert sich
> nicht wie eine Standard-Funktionalitaet von Update an:
>
> Angenommen, Saetze bilden "mehrere Primaerschluessel" (die Eigenschaft
> "Primaerschluessel" ist dabei nicht in der Datenbank hinterlegt), dann
> wirken alle Primaerschluessel der bereits in der Datenbank vorliegenden
> Schluessel bei folgendem Vergleich, der fuer jeden Update-Satz durch-
> gefuehrt wird: "Kann ich den /ersten/ gebildeten Schluessel dieses
> Datensatzes in der Datenbank bereits finden?"

Ich will bei meinen zu importierenden Datensätzen
-- zuerst prüfen, ob die PND in der Datenbank vorhanden ist,
-- falls nicht nachsehen, ob die ZKA-Nummer da ist
-- und, falls beiden fehlschlägt, prüfen, ob ich den Namen finde.

Alle entsprechenden Schlüssel müssen in der Datenbank schon vorhanden sein, ich weiß aber nicht, wie ich die drei Tests auf einen Schlag mit den zu importierenden Daten erledigen könnte.

> > Ein einzelnes ASCII 01 in der letzten Zeile wird übrigens mit
> > "Fehler bei der Bearbeitung von #005p.hlg. Datei endet abrupt"
> > quittiert, das macht aber wohl nichts.
>
> Nun, die Fehlermeldung ist angebracht und sogar zutreffend formuliert,
> ob das "nichts macht" muss der Anwender entscheiden, denn bei einer
> abgeschnittenen Datei kann die Maschine hoechstens Raten ob es ein
> Fall von "zuviel" (Schmutz hinter dem letzten Datensatz) oder "zuwenig"
> (500.000 Saetze sind einem Plattenschaden zum Opfer gefallen) ist.

Naja, ein einzelnes ASCII 01 in einer xLG-Datei ist funktional äquivalent zu einer zusätzlichen Leerzeile in einer xDT-Datei, da würde wohl auch nicht groß gemeckert.

Mit freundlichen Grüßen
Thomas Fischer