[Allegro] a99 und acon vorab zum Testen

[Bernhard Eversberg]

Am 31.08.2015 09:41, schrieb Klaus Lehmann:
>
> hier schon ein blick in ein UPRO-log:
> mit -fm41
>
> DEN satz findet er
> ==================
> 1. [09:21:13] 1196705. Satz eingelesen :
> 2. Gesucht: >|9 Duer skal flyve frit i himlen (2010)=?<
> 3. Gesucht: >|9 Duer skal flyve frit i himlen (2010)<
> 4. 1196705. Satz = #2581020 gefunden: >|9Duer skal flyve frit i himlen (2010)<
> 5. [09:21:13] Satz #2581020 ersetzt (Datei 55, Laenge 1951)
>
> ich hab mal nummern davor gesetzt...
> 3.  ist doppelt gemoppelt. oder ergibt 2+3 EINE zeile zusammen: quasi das
> protokoll des abgleichs des primären schlüssels?!
>
Ja, so ist das. Zuerst wird immer mit '=' geprueft, weil's ja sein kann,
daß der Prim.Schl. zugleich Ersetzungsschlüssel ist.

>
>
> achtung: androhung ;-)
> es  kann  sein,  daß  ich laufe des tages "beweise" vorbringe, daß ein
> sehr langer PS, der über 245 zeichen geht, NICHT in den ersten zeichen
> vergleichbar ist. sprich: daß es dann zu solchen einträgen kommt:
> 4. Status: Nichts gefunden 0
> 5. [19:27:09] Neusatz gespeichert in Datei 209 (Laenge 1086)
>
Das ist nicht unser Bier. Schlüssel haben per se eine begrenzte Länge,
das steht auch im "Grenzen"-Papier, da kann der der Prim.Schl. keine 
Extrawurst kriegen.
Was helfen *könnte*, wäre eine Aufbohrung des update.job an der Stelle, wo
er mehr als einen Satz zu einem Schlüssel findet. Da müßte er dann die 
einzelnen
Sätze laden und die Titel direkt vergleichen, also nicht die Schlüssel.
Weil sich das nicht standardisieren läßt sondern rein
anwendungsspezifisch ist, können wir's nicht einbauen in den 
Standard-update.job


B.E.







B.E.