[Allegro] a99 und acon vorab zum Testen

[Klaus Lehmann]

nur erklärend....

> Am 31.08.2015 09:41, schrieb Klaus Lehmann:
...
>> 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.

ja. das ist klar. in die richtung will ich gar nicht.

aber ich habe der "verdacht", daß WENN ein solcher PS zu lang ist [wir
schneiden ihn ja auch bewusst ab mit:
#-@
#00 y0 e245 p"|9"
#+#


... also: wenn er zu lang ist, findet in den ersten 245 zeichen keine prüfung
statt. ich habe ganz leise den verdacht....

nicht  verständlich?
ja,  sicher.  deshalb ja nur die "androhung" ich
brauche  nen  beweis.  bei "anke engelke" und den "ladykrachern" finde
ich ihn. irgendwann im laufe des tages..... evtl.

vielleicht  war  ja  meine  sicht getrübt, durch das helle licht, was
oberhalb   von  3000metern  gleisst.  will  sagen:  erstmal  alle  dt.
sonderzeichen raus bzw ersetzt!

also: später mehr


grüße
k.l.



> 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
~~~~~~~~~~~~~~ bitte: was ist "ein Satz"?
der  konstruktion  des  PS's sollte es doch egal sein, was drin steht,
hauptsache:   die   nicht   erlaubten   sonderzeichen  werden  (nicht)
berücksichtigt. (in meinem fale VORHER umgewandelt...)


gruß k.l.



> 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