AW: Dubletten beim Einsatz von SRCH

[Fischer, Robert]

Lieber Herr Englert,

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

Doch noch eine Nachfrage zum eindeutigen und praezisen Verstaendnis:

Sowas kann man schon produzieren, dazu brauchts kein Netzcaching.

Was steht in Ihrer CFG?
Es geht um die Zeilen, wo cg und ci vereinbart werden, sind beide aktiv?

Sie haben die Satznummernmechanik als in der Abfrageliste enthalten genannt:
00 " Ident-Nummer: "dk0?<

Wenn man _kein_ cg vereinbart hat, wohl aber ein ci, dann kann man beim
Kopieren eines Satzes mit C sehr wohl zwei Versionen des Satzes mit gleicher
ID in #00 erhalten, die #00 bleibt naemlich dann einfach stehen, was man
normalerweise auch sieht.

Das nutzen wir fuer bestimmte Zwecke. Nur bei Neusatz ueber Abfrageliste
gibts dann echt neue IDs in #00.

Die Spurensuche laesst sich aber verfeinern:
Wenn Sie regulaere #99n und #99e stempeln lassen, und diese sind lang genug
(mit Sekunden) dann hat man:

#99n identisch, #99e vh / 00  im 2.Satz = Programmfehler
#99n ungleich, keine #99e im 2. Satz = Kopie (Menschenfehler)

Wenn Sie nicht stempeln lassen, dann haben wir da allerdings als Detektive
Pech.

Vielleicht ists kein bug, sondern eine ergaenzbare CFG?

Es gab uebrigens sehr wohl frueher nicht lokalisierbare aber _auesserst
seltene_ Fehler, die fuer Saetze selbst im Singlebetrieb Indexeintragungen
ganz oder teilweise loeschten oder auch nicht eintrugen. Deshalb die Frage
nach der Version.
Pruefen laesst sich das bei Datenbanken unter 16000 Saetze leicht ueber
Ergebnismengen/hoechste Satznummer/geloeschte Saetze, ueber 16000 hilft nur
ein Export.

Mit freundlichen Gruessen

Robert Fischer
rfb at blinx.de
*****************************************