[Allegro] a99 und acon vorab zum Testen

Klaus Lehmann lehmann_klaus at t-online.de
Mo Aug 31 12:48:56 CEST 2015


....
> Im update.job steht aber
> var p
> var (0,246 e"=" F" ")
> ins $primkey
> und das heißt, daß die i3-Zeichen in den F-Befehl mit einbezogen werden
> sollten, FALLS man damit rechnet - wie man es im Falle Lehman tun muß,
> der Prim.Schl. länger werden kann als 246, denn dieser Fall wird bei
> "var p" nicht abgefangen. Unsere Vorstellungskraft, zugegeben, hat an
> der Stelle versagt. Aber ist ja noch nicht zu spät, wir ergänzen das in
> a99 und acon.
> B.E.

sie schauen sich jetzt den update.job an!
ist denn der blick dann auf die cat.api falsch? überflüssig?
oder  sollte  an  beiden  orten angesetzt werden?
damit dann auf keinen fall was schiefgehen kann, wenn man den einen ort vergessen hat?


gruß k.l.
ps:   wohlwissen:  WER  hat  schon  so  voluminöse  PS'?
es  ist  ein spezialfall...


-- 
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 11:58 schrieben Sie:
> Am 31.08.2015 11:15, schrieb Thomas Berger:
>>>
>>> ... also: wenn er zu lang ist, findet in den ersten 245 zeichen keine prüfung
>>> statt. ich habe ganz leise den verdacht....
>>
>> Ich wuerde davon ausgehen, dass die i3-Zeichen der .cPI, die beim
>> Einsortieren der Schluessel am Ende automatisch beseitigt werden,
>> weder von "var p" noch vom update.job beruecksichtigt werden:
> ...

> Sie gehen hier bzgl. "var p" von einer, wie Sie selber einräumen, nicht
> getesteten Mutmaßung aus. Diese entbehrt normalerweise der
> Stichhaltigkeit, wie wir nach sowohl Test wie auch
> Quellcodeeinsichtnahme bestätigen können.

> Im update.job steht aber

> var p
> var (0,246 e"=" F" ")
> ins $primkey

> und das heißt, daß die i3-Zeichen in den F-Befehl mit einbezogen werden
> sollten, FALLS man damit rechnet - wie man es im Falle Lehman tun muß,
> der Prim.Schl. länger werden kann als 246, denn dieser Fall wird bei
> "var p" nicht abgefangen. Unsere Vorstellungskraft, zugegeben, hat an
> der Stelle versagt. Aber ist ja noch nicht zu spät, wir ergänzen das in
> a99 und acon.

> B.E.


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




Mehr Informationen über die Mailingliste Allegro