Scheitern des Indexlaufs

Thomas Berger ThB at gymel.com
Mi Feb 27 17:53:47 CET 2002


Lieber Herr Eversberg,

> > Herr Eversberg versprach damals (glaube ich mich zu
> > erinnern), das Problem fuer eine der kommenden
> > Versionen zu entschaerfen.
> >
> Hat er auch gemacht. Es gibt eine Option -B dafuer.
> Sagen Sie
> index ... -B25000
> und schauen Sie, was dann passiert. Default ist 8000 (nicht 10000).

Aber 10.000 bei PRESTO?

Leider ist es mir trotz aller Hilfestellungen noch nie
gelungen, durch einen Export (mit einer schematisch
nach .cPR umgewandelten .cPI) eine verlaessliche
Schaetzung fuer die "maximale Schluesselsumme"
einer gegebenen Datenbank zu bekommen.

Koennten Sie nicht in der Protok eine zweite Ausgabe
analog

 max. Anzahl Schlüssel je Satz: 307  (= Satz# 198890)

spendieren, etwa

 max. Schluesselspeicher: nnn Bytes (= Satz# nnn)


Aber auch das hilft eigentlich nicht viel, wenn die
Indexierung wegen dieses Problems zusammenbricht.

Weitere Vorschlaege: 
- die Meldungen wg. begonnener und beendeter .ald-Dateien
  auch in die PROTOK-Datei schreiben (das hilft bei der
  Eingrenzung von Problemen, denn bei grossen Datenbanken
  mag man nicht x-Stunden vor dem Monitor sitzen, um die
  Meldungen zur Kenntnis zu nehmen)
- Warnmeldungen wegen zu vieler Schluessel und zu grosser
  Schluesselsumme ausgeben (sind ja oft in dem Sinne 
  unproblematisch, dass INDEX.EXE diese Spezifikations-
  ueberschreitungen partiell "ueberlebt")
- Abbruch bei Fehlern (derzeit haspelt INDEX.EXE ja munter
  weiter, produziert Stundenlang II-Dateien der Laenge 0
  bzw. sogar plausibler Laenge mit korrupten Eintraegen),
  erst am Ende gibt es dann den "Speicherzuordnungsfehler".

viele Gruesse
Thomas Berger




Mehr Informationen über die Mailingliste Allegro