[Allegro] a99 und acon vorab zum Testen : nochwas!

Mo Aug 31 11:31:01 CEST 2015

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

was ich da oben notiert habe, stand im UPRO-protokoll!
sehr hübsch. sehr verständlich!

NEUES BEISPIEL!
===============
aber auf dem cmd-fenster ist das alte zu lesen
52292. Satz  :  >|9Chui si tian e (1967)<N:<E130> kein Ergebnis bei: |9 "Chui si
 tian e (1967)=?"
 ==> x (Satz #2481807 ersetzt)
M: Satz 2481807 gespeichert

währendessen es im UPRU gut aussieht:
[11:24:24] 52292. Satz eingelesen :
Gesucht: >|9 Chui si tian e (1967)=?<
Gesucht: >|9 Chui si tian e (1967)<
52292. Satz = #2481807 gefunden: >|9Chui si tian e (1967)<
[11:24:24] Satz #2481807 ersetzt (Datei 53, Laenge 1933)

also hat die bildschirmanzeige (stdout) noch ein problem....

gruß k.l.

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

> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro

-- 
Mit freundlichen Grüßen,
Ihr Klaus Lehmann
http://allegronet.de * eMail: allegronet at t-online.de * phone: 03528-452 807(fax 809) * mobil: 0171-953 7843
allegronet.de * Klaus Lehmann * D-01454 Radeberg * Bahnhofstr. 1
zuständiges Finanzamt: FA Hoyerswerda; zuständige Kammer: IHK Dresden;
zuständige Aufsichtsbehörde: Gewerbeamt Radeberg; USt-IdNr: DE247550760
* Software für zufriedene Bibliothekare: 1000x bewaehrt und ergiebig
* Bereits 4x allegro-utf8. Buchen Sie die allegro-Roadshow. Yes we can!
* Internetkataloge & WebHosting für Allegro-C & Web 2.0 mit VuFind
* 2011: Sponsor der Peter-Sodann-Bibliothek (Staucha)
* 2012: mit allegro-utf8 V3 und allegro-vufind auf der IFLA in Helsinki
* 2013: Bolero 64bit. Fußige Noten aufgeblättert (=Die Fußnotendoku)
* 2014: allegro-zdb: endlich. Die Wiedervereinigung! + eBooks
* 2015: allegro-vufind. Endlich! Noch moderner! Web2 auch für Ihren Katalog?

Am Montag, 31. August 2015 um 10:07 schrieben Sie:
> 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.

> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro