AW: Dubletten beim Einsatz von SRCH

[Gerhard Englert]

Lieber Herr Berger,

bevor ich weiter Infos und Fragen verbreite, werden wir erst einmal
sicherstellen, dass wir version 22.2 verwenden.


Haben wir bisher nicht getan, da wir die fehler bisher zumindest nicht
bemerkt haben. Ich _glaube_ aber, dass wir die Fehler bisher auch so nicht
hatten , denn auch Access mag keine doppelten Satzschlüssel.
Da wir momentan häufig Engpässe im Netz haben,  _glauben_  wir laienhaft
eher, dass da irgendwas auf der Strecke bleibt.

Auf Presto bezogen meint Dublette "verschieden Sätze mit identischer
Satznummer", die man im Index finden kann.
Sowas hatte wir schon früher einmal, auch schon einmal ohne Antwort
nachgefragt.


Erschreckende und neu dazu gekommen ist letzte Woche:
"verschiedene Bearbeitungszustände eines Satzes mit identischer Satznummer",
die erst bei einem Export mit Srch (oder wie gestern getestet bei Neuindex)
zu Tage treten.

Mit freundlichen Grüßen

G. Englert
Informations- und Datenzentrum

Tel 0531-596 1534


> -----Ursprüngliche Nachricht-----
> Von: Maiser at buch.biblio.etc.tu-bs.de
> [mailto:Maiser at buch.biblio.etc.tu-bs.de]Im Auftrag von Thomas Berger
> Gesendet: Freitag, 22. November 2002 19:07
> An: Diskussionsliste Allegro-C
> Betreff: Re: Dubletten beim Einsatz von SRCH
>
>
> Lieber Herr Englert,
>
> ich habe nicht alle Ihre Mails aufbewahrt, daher nehme
> ich jetzt nur einmal an, dass "Dublette" hier meint,
> zwei *verschiedene* Saetze mit gleicher Identnummer
> (und nicht zwei Bearbeitungsstaende desselben Datensatzes)
>
>
> > Obwohl wir über externe Prüfroutinen über den Index 100%ig sicherstellen
> > können, dass im INDEX keine Dublette vorkommt, wird im
> Srch-Exportlauf eine
> > Dublette ausgegeben. Einmal identifiziert findet man auch im Logfile die
> > entsprechenden Arbeitseinträge. Dort sieht aber für uns Laien
> alles sauber
> > aus. Ein anschliessender Srch-lauf über den entsprechenden ALD-file
> > produziert denn auch brav wieder 2 Ergebnisse.
>
> Ziemlich klarer Fall: Der Indexeintrag fuer eine Identnummer war
> nicht gebildet worden, daher wurde dann anhand des Indexes etwas
> spaeter dieselbe Identnummer noch einmal errechnet.
>
> > Jetzt ergibt sich eine etwas veränderte Fragestellung:
> >
> > Unter welchen Bedingungen kann es passieren, dass bei braver!!
> Arbeit mit
> > Presto ein bearbeiteter Datensatz so zurückgespeichert wird,
> dass er keinen
> > doppelten Indexeintrag erzeugt, aber trotzdem für srch noch exportierbar
> > vorliegt?
>
> Hm. War es also doch derselbe Datensatz, der bei einer
> Bearbeitung ploetzlich dupliziert wurde, und zwar so,
> dass alle Schluessel auf die "neue" Version zeigen, die
> alte Version (mit neuer Satznummer) aber nicht als
> "getilgt" eingetragen ist?
>
> Gegenfrage: Sie benutzen doch hoffentlich die Executables
> von Version 22.2 oder neuer, nicht wahr?
>
> viele Gruesse
> Thomas Berger