index/qrix: immer noch probleme -akut- folge 3

[Thomas Berger]

Hallo Herr Lehmann,

> 10x ii??-dateien bleiben nach dem letzten index-gang übrig.
> index.exe müsste jetzt die eigens vom system erzeugte qs.bat aufrufen.
> (WER erzeugt diese datei qs.bat? ist es index.exe?)

Ja, aber aufgerufen wird die qs.bat nicht von index.exe sondern
z.B. von der Cockpit-generierten ccc.bat

Wenn es also nicht aufgerufen wird, liegt es daran, dass entweder
acp.exe recht alt ist oder aber Sie mit einem selbstkreierten
Aufruf indexieren.

 
> EHE die qs.bat ihren dienst versehen kann, gibts einen c-tree error 230 (!), und die qs.bat wird NICHT
> gestartet.
> 
> so siehts aus:
> 
>  INDEX 6 wird bearbeitet
>  INDEX 6 enthält 114778 Einträge
>  INDEX 7 wird bearbeitet
>  INDEX 7 enthält 144207 Einträge
>  INDEX 8 wird bearbeitet
>  INDEX 8 enthält 60396 Einträge
>  INDEX 9 wird bearbeitet
>  c-tree fatal error #230.C:\INDEX\PROTOK

Normal (seit Herbst 2000 oder 2001).


> ich berichtete früher, daß die qs.bat automatisch NACH dem c-tree-error gestartet wurde.
> !JETZT leider nicht!

s.o.

 
> ich habe die letzten monate gedacht, es läge an den neuen index.exe's, bin auf eine von 6. märz 2003
> zurückgegangen. da ging es ein weilchen. bis auch diese bei einer 

nicht weit genug. Es liegt tatsaechlich an index.exe und dessen
Zusammenspiel mit qrix.exe, wobei ich die Schuld eher bei index.exe
sehe, denn direkter Aufruf von qrix.exe (wie etwa durch qs.bat)
bringt ja keine Probleme.


> ich behelfe mir gerade, in dem automatisierten index_lauf, daß ich da die qs.bat etwas abgewandelt einbaue:
> 
> rem hier sind die normalen
> 
> rem zum testen und zum sehen
> if exist c:\index\ii1. dir c:\index\ii1.
> if exist c:\index\ii1. echo.
> if exist c:\index\ii1. pause
> 
> rem auf c:\index wird/wurde der indexvorgang ausgeführt
> if exist c:\index\ii1. goto QSS_YES
> if not exist c:\index\ii1. goto QSS_NOT
> 
> :QSS_YES
> o:\allegro\qrix -kAlsm -fq1 -dC:\INDEX -elsm/C:\INDEX -K150 -yC:\INDEX\ -lGER -Po:\allegro
>  a -x9999
> goto QSS_NOT
> :QSS_NOT
> 
> so gehts, schön ist das aber nicht!

dafuer wurde ja eingefuehrt, dass qs.bat den jeweils notwendigen
qrix-Aufruf enthaelt. Also (vgl. die Cockpit-generierte ccc.bat):

...
if exist c:\index\ii1 call qs
if [immer noch] exist c:\index\ii1 goto grandioskaputt
...


> liegt der fehler in der datenbank?
> index.exe sagt doch: c-tree-error 230(!), (nicht 231 oder etwas anderes!)
> 
> einmal beobachtet: c-tree-error bei index 3
> heute -aktuell- tauchte er erst bei index 10 auf.

Der Fehler taucht exakt an der Stelle auf, wo das erste
Register bearbeitet wird, in dem die .adx aus dem 
ersten Indexlauf bereits Eintraege hat. Bei einer
Datenbank mit Leersaetzen z.B. bereits bei Register 1.

 
> trotzdem: es kann nicht die datenbank (=ald's) sein, dann würde der selbe c-tree-error an der gleichen
> stelle des jeweiligen index-vorganges auftauchen!
...
> ps. mir fällt ein, daß ich diesen fehler nicht immer wiederholen konnte. am einsatzort des geschehens ja.
> im testlabor nicht. also könnte es etwas betriebssystemspezifisches sein....(?)

Dass genau 10 ii-Dateien fuer die letzte Phase uebrigbleiben hat
nicht nur mit Datenbank und Parametern, sondern auch mit dem
Betriebssystem zu tun: Starken Einfluss hat der freie Arbeitsspeicher
unter DOS, der ja die maximale Groesse der von Index gebildeten
urspruenglichen ii-Dateien bestimmt.

viele Gruesse
Thomas Berger