[Allegro] acon bringt fehler: "Befehl nicht korrekt geformt"

[Klaus Lehmann]

> Berger bringt vor, man könne doch besser die Grenze auf 8000 hochsetzen,
> so daß das "andere Limit" von 32000 Byte Gesamtvolumen dann i.a.
> vorher erreicht würde.

[meine denke:]
das schlimme an grenzen ist, auch wenn sie bekannt sind und "befolgt" werden, sie werden IMMER irgendwann durchbrochen.
also bringt es nichts, die grenzen bis zur "unendlichkeit" 
hochzusetzen. 
dann lieber [s.a. ganz unten bitte weiter:]

> Hinweise dazu:
> Man kann z.B. die ak-Zeilen auch so anordnen, daß die vermutlich weniger
> wichtigen Schlüssel als letzte gebildet werden!
[s.a. ganz unten bitte weiter:]

> Natürlich ist Platz kein Problem und die Rechner werden dank Moore
> alle 2 Jahre doppelt so schnell. Gleichwohl ist bedenkenloser
> Ressourcenverbrauch das historisch sicher folgenreichste Merkmal

tja, wir wollen immer mehr. die grenze, an die schon mal geklopft 
habe, war 2GB bei der einzelnen(sic)indexdatei, wenn man diese grenze 
erkannt nun hat, kann man noch "ein wenig" ausweichen ;-) 
->adx,aex,afx,agx usw usw.
[das thema hatten wir ca vor 1/2 - 1 jahr...]


> unseres Zeitalters, das sich auch hier manifestiert. Auch und
> gerade darin, daß solche Hinweise entrüstet oder amüsiert verworfen
> werden.
;-)

> Vielleicht wäre es bei diesem Lichte besser, das "andere Limit"
> ein wenig herabzusetzen. ;-) Und eben acon beizubringen, in solchen
> Fällen einen Hinweis auszugeben.
etwa hinweise im proto[qk]ol: 
"beim datensatz xyz sind die grenzen der schlüsselbildung von 1200 
erreicht. es wurde trotzdem weitergemacht"
"beim datensatz xyz sind die grenzen der schlüsselbildung von 32.000bytes erreicht. es wurde trotzdem weitergemacht"
[so ähnlich, daß man den datensatz GENAU identifizieren kann...]

es fragt sich natürlich, geht das auf die performance? 
wohl ja .....

idee: vielleicht kann man diese fehlerüberprüfung nur mit einem 
parameter oder schalter aktivieren? -Lf ("f" erweitert die logdatei 
auf fehlerhinweise). 
oder so ähnlich ...


grüße
k.l.





> 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





Am Freitag, 14. November 2014 um 09:27 schrieben Sie:
> Am 14.11.2014 08:52, schrieb Klaus Lehmann:
>>
>>> Es war ein Folgefehler. Der eigentliche Grund ist: Es entstehen bei
>>> einem Satz mehr als 1000 Indexeinträge.
>> ....
>>> und mit der 0 dann überschrieben wird. In diesem Fall ging's dann
>>> wirklich schief. Die beobachteten Meldungen weisen auf den eigentlichen
>>> Tatbestand nicht hin, das ist aber typisch in solchen Fällen.
>>
>>               ~~~~~~~~~  ja. leider. das machte es ja so schwierig für
>>               mich, überhaut zu erkennen, daß da IN der gegend ein
>>               fehler vorgelegen hat.

> Für uns doch auch! Was für ein Werkzeug hätte denn wohl helfen können?
> Das war ein Programmfehler, wie er einem guten Programmierer nicht
> passieren darf, dagegen ist kein Kraut gewachsen. Das Programm acon
> hätte das abfangen müssen und das tut es jetzt auch, der Fehler wird
> nicht mehr auftreten, auch bei überlangen Sätzen nicht. Unsere Schuld,
> zugegeben, und wir hatten's ja auch auszubaden, nicht weniger als Sie,
> die Sache aufzuklären.

> Denkbar wäre nun ein Werkzeug, das diejenigen Sätze ermittelt, die mit
> der Anzahl ihrer Schlüssel an die Grenze stoßen, sowas haben wir noch
> nicht. Hätte aber auch nicht geholfen beim Einspeisen neuer Sätze mit
> acon. Da hilft nur ein korrektes Programm, und das haben wir nun, denn
> *dieser* Fehler ist jetzt einfach weg. acon könnte aber einen Hinweis
> ausgeben in der Protokolldatei, das ist zu überlegen und das hätte
> helfen können.

> Berger bringt vor, man könne doch besser die Grenze auf 8000 hochsetzen,
> so daß das "andere Limit" von 32000 Byte Gesamtvolumen dann i.a.
> vorher erreicht würde.
> Hinweise dazu:
> Man kann z.B. die ak-Zeilen auch so anordnen, daß die vermutlich weniger
> wichtigen Schlüssel als letzte gebildet werden!
> Bedenken Sie aber auch, daß das Indexieren und damit auch das Speichern
> eines Satzes umso mehr Zeit braucht, je mehr Schlüssel man macht.
> Und wer moderne Suchverfahren will, für den sind alphabetisch sortierte
> Register eh nicht mehr diskutabel, der wird so etwas wie VuFind
> anpeilen wollen - und dieser Weg steht ja auch offen.
> Natürlich ist Platz kein Problem und die Rechner werden dank Moore
> alle 2 Jahre doppelt so schnell. Gleichwohl ist bedenkenloser
> Ressourcenverbrauch das historisch sicher folgenreichste Merkmal
> unseres Zeitalters, das sich auch hier manifestiert. Auch und
> gerade darin, daß solche Hinweise entrüstet oder amüsiert verworfen
> werden.
> Vielleicht wäre es bei diesem Lichte besser, das "andere Limit"
> ein wenig herabzusetzen. ;-) Und eben acon beizubringen, in solchen
> Fällen einen Hinweis auszugeben.

> B.E.

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