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

[Thomas Berger]

Hallo Herr Fischer,

>> 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.

weil update.job UPDATE.exe nachgebildet ist, durchlaufen auch bei
anderen Modi die Neusaetze m.W. nicht die Exportparameterdatei.


>> 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?

"das" habe ich bislang immer mit einem dem Update nachgelagerten
Export (Abgleich mittels srch) der Update-Datei gegen die Datenbank
gemacht. Letztendlich gibt es dabei nur ein Problem: Update "schenkt"
einem die Primaerschluesselbestimmung per .cPI, mit SRCH muss man
das in die Exportparameter integrieren, wohl dem, der das auch in der
cPI mit einem Unterprogramm gemacht hat, das auch anderswo als in die
.CPI eingebunden werden kann. In diesem Fall gibt einem ein regulaerer
Export mit SRCH wesentlich mehr Testmoeglichkeiten, denn hier koennen
ja mehrere gebildete Primaerschluessel der Reihe nach gegen die
Datenbank gematcht werden um zu komplexeren Zuordnungen zu kommen, denn
Update vergleicht - wie vorhin erwaehnt - stets nur den ersten des
jeweiligen neuen mit allen aller alten.


> Und sehe ich das Recht, das es bei dem A99-Update kein Äquivalent zu -fc gibt?

zu -e auch nicht.


>>> 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.

[Kein Kommentar zur Sinnhaftigkeit des Vorhabens]

Das ging und geht definitiv nicht mit update.exe oder update.job.
Sie koennen entweder einen gepatchten Update.job nutzen oder die
Zuordnungslogik in einen vorgelagerten Export verlagern, der mit
zwei parallelen Parameterdateien durchgefuehrt wird:

Die erste Parameterdatei bestimmt die zu testenden Schluessel,
testet die gegen die Zieldatenbank und entscheidet, ob der Satz
passt: In diesem Fall wird der Satz exportiert, allerdings mit
ggfls. so veraenderten Kategorien, dass er mit dem nachfolgenden
Update auch wirklich den soeben identifizierten Satz trifft (das
erfordert i.A. auch eine modifizierte Indexparameterdatei fuer das
Update). Ausserdem wird eine Anwendervariable gesetzt die dazu
fuehrt, dass der parallele Export nichts tut (ausser die
Variable zurueckzusetzen). Entscheidet sich der erste Export
gegen die Uebernahme, dann bleibt die Variable unbesetzt und
der parallele Export kommt zum Zug.

zur "modifizierten Indexparameterdatei" folgendes Bild: Wenn der
neu hereinkommende Satz tendenziell mehr Identnummernkandidaten
hat als der eventuell vorhandene, dann sind dabei auch u.U.
"staerkere" (solche, die frueher als die anderen berechnet werden).
Hier ist dann die paradoxe Situation, dass der vorhandene Satz den
Neusatz stets treffen wuerde, jedoch (das Originalproblem) der
Neusatz niemals den vorhandenen treffen kann: Der Neusatz hat den
staerkeren Schluessel, der ist in der Datenbank nicht vorhanden
und das Update entscheidet auf "Neusatz" ohne jemals die im Neusatz
ebenfalls vorhandenen schwaecheren Schluessel zu pruefen. Nun
wollen Sie aber nicht ausgerechnet die Kategorie mit der wertvollen
Anreicherung verwerfen, die zum "staerkeren" Schluessel gefuehrt hat.

Hier kann man dann ganz allgemein so vorgehen: Den Primaerschluessel,
der tatsaechlich zum Treffer gefuehrt hat, in einer bislang noch
nicht belegten Hilfskategorie ablegen und die Indexparameter so
aendern, dass diese Hilfskategorie mit hoechster Prioritaet zur
Schluesselbildung herangezogen wird. Durch die Globale Manipulation
beim Update oder spaeter interaktiv kann die Hilfskategorie dann
aus den ueberfuehrten Datensaetzen wieder geloescht werden.


> 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.

Ich glaube, Sie verwechseln das jetzt mit einer zusaetzlichen Leerzeile
in einer .cLG-Datei... Ist aber auch egal, weil "funktional aequivalent"
im Handbuch gar nicht vorkommt.

viele Gruesse
Thomas Berger