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

Klaus Lehmann lehmann_klaus at t-online.de
Do Nov 27 09:31:28 CET 2003


On Wed, 26 Nov 2003 21:02:50 +0100, Thomas Berger wrote:

guten tag herr berger
danke für ihre erhellende antwort. somit wird vieles klarer..

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. 

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.




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

bingo. 
selbstgekraierter aufruf. 
cockpit ist nix für "meine" anwender ;-)


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

hm. normal.... normal dann für ca 10-120 prozent der fälle. es taucht ja nicht überall (bei mir) auf.....
?!




kl>> ich habe die letzten monate gedacht, es läge an den neuen index.exe's, bin auf eine von 6. märz 2003
kl>> zurückgegangen. da ging es ein weilchen. bis auch diese bei einer 
kl>
kl>nicht weit genug. Es liegt tatsaechlich an index.exe und dessen
kl>Zusammenspiel mit qrix.exe, wobei ich die Schuld eher bei index.exe
kl>sehe, denn direkter Aufruf von qrix.exe (wie etwa durch qs.bat)
kl>bringt ja keine Probleme.

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 ....)



kl>> liegt der fehler in der datenbank?
kl>> index.exe sagt doch: c-tree-error 230(!), (nicht 231 oder etwas anderes!)
kl>> 
kl>> einmal beobachtet: c-tree-error bei index 3
kl>> heute -aktuell- tauchte er erst bei index 10 auf.
kl>
kl>Der Fehler taucht exakt an der Stelle auf, wo das erste
kl>Register bearbeitet wird, in dem die .adx aus dem 
kl>ersten Indexlauf bereits Eintraege hat. Bei einer
kl>Datenbank mit Leersaetzen z.B. bereits bei Register 1.

gut, also das erklärt, warum es mal bei index3 oder mal bei index 10 auftaucht...
(heisst das nun register oder index? ;-)



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"?

wenn "JA", dann müsste es ja eben bei meinen installationen, eben zu "weniger c-tree-errors" kommen. denn jede dos-box ist nach allen regeln 
der künste mit maximalem dos-arbspeicher ausgestattet (himem.sys, high,umb usw usw)




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.... !!!!

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!- !


damit wäre auch dieses thema erledigt
(sollte sich das thema vielleicht in der doku wiederfinden? ;-)


viele grüße
ihr
k.lehmann

-- 
Klaus Lehmann
eMail: lehmann_klaus at t-online.de
*** allegro-C-Dienstleistungen: 
Datenbankbereinigungen, Safer Shells, Fehlerindices, 
komplette Arbeitsumgebungen, Fremddaten:Import/Export;
Batchprogrammierung & andere Automatismen
Admin fuer Netware/Win3X-XP/VOEBB/Linux/Samba Friedrichshain-Kreuzberg;
*** Our best ideas are born at home (New Freedom Data Center 1995) ***






Mehr Informationen über die Mailingliste Allegro