index/qrix: immer noch probleme -akut- folge 3 (und ende)

[Thomas Berger]

Hallo Herr Lehmann,

> kl>> 10x ii??-dateien bleiben nach dem letzten index-gang übrig.
> kl>> index.exe müsste jetzt die eigens vom system erzeugte qs.bat aufrufen.
> kl>> (WER erzeugt diese datei qs.bat? ist es index.exe?)
> kl>
> kl>Ja, aber aufgerufen wird die qs.bat nicht von index.exe sondern
> kl>z.B. von der Cockpit-generierten ccc.bat
> 
> das kann so nicht ganz stimmen, da ich in diesem zeitpunkt z.b. NICHT a99, acp oder cockpit wie auch immer verwende.
> also wird diese datei, die ich im index-verzeichnis entdecke, entweder von index.exe oder qrix.exe erzeugt.
> cockpit ist hier raus aus dem geschäft.

noch einmal ganz klar:

index.exe erzeugt qs.bat und hinterlegt dort den qrix-Aufruf,
den es zu tun gedenkt (genau wie in protok)

index.exe ruft qrix auf

wenn nun qrix scheitert, ist es nun jemand anderes Aufgabe,
qs.bat zu starten, um den qrix-Aufruf zu wiederholen.


 
> aber die beantwortung wäre rein akademischer natur, es sei denn, sie führt auf den grund des fehlers! denn es kann ja nicht sein, dass es
> eine hilfskrücke a'la qs.bat geben MUSS, um in den meisten(?) fällen sauber zu indexieren.

Die Entwicklungsabteilung hat lange nach dem Fehler gesucht,
warum sie ihn nicht gefunden hat, kann ich nicht beantworten.
Die erzeugte QS.BAT prophylaktisch aufzurufen ist nun (seit 
einigen Jahren also) der Workaround, der funktioniert.
10 Zwischendateien in der letzten Phase haben Sie naiv
gerechnet bei ca. 11% aller Datenbanken, in der Praxis (das
Wachstum miteinberechnen) in deutlich weniger Faellen.



> gut, möchte ich also auf die anwendung von qs.bat verzichten, muss ich eine index.exe von vor früher als 2001/2000 verwenden...?! (siehe
> oben ....)

warum sollten Sie auf die Anwendung von qs.bat verzichten wollen
(ausser zukuenftige Versionen von index/qrix haben den Fehler
nicht mehr?). Seit November 2000 oder 2001 ist das Problem
konstant, fruehere Versionen hatten es ca. ein Jahr lang auch,
dann wieder nicht, wenn ich mich recht entsinne. Auf der
sicheren Seite sind Sie vermutlich erst, wenn Sie auf eine
allegro-Version zurueckstufen, die zweistufige Indexierung
noch nicht beherrscht.


> kl>> trotzdem: es kann nicht die datenbank (=ald's) sein, dann würde der selbe c-tree-error an der gleichen
> kl>> stelle des jeweiligen index-vorganges auftauchen!
> kl>...
> kl>> ps. mir fällt ein, daß ich diesen fehler nicht immer wiederholen konnte. am einsatzort des geschehens ja.
> kl>> im testlabor nicht. also könnte es etwas betriebssystemspezifisches sein....(?)
> kl>
> kl>Dass genau 10 ii-Dateien fuer die letzte Phase uebrigbleiben hat
> kl>nicht nur mit Datenbank und Parametern, sondern auch mit dem
> kl>Betriebssystem zu tun: Starken Einfluss hat der freie Arbeitsspeicher
> kl>unter DOS, der ja die maximale Groesse der von Index gebildeten
> kl>urspruenglichen ii-Dateien bestimmt.
> 
> hm..... gilt die formel "je größer der freie dos-arbspeicher, dann je weniger c-tree-errors"?

nein. Wenn Sie einen c-tree-error erleben, koennte Reduktion des
DOS-Speichers um 10kB ihn fuer die naechsten 5 Jahre beheben...

 
> resümierend:
> 1. es muss also in den JEDEN freiprogrammierten index-lauf der inhalt der qs.bat eingebaut werden, so wie oben schon dargestellt: if und if
> not.... !!!!

Nein, qs.bat wurde eingefuehrt, damit man nicht jedem Index-Aufruf
den qrix-Aufruf dazubauen muss, sondern einfach nur einen qs-Aufruf.



> 2. wenn man die routinen aus dem cockpit benutzt, oder index aus a99 (füllhorn) aufruft, ist dieses nicht nötig -ja gar nicht möglich!- !

so ist es.

viele Gruesse
Thomas Berger