zu: index-problem bei großen datenbanken (über 4 mill datensätze)

[Klaus Lehmann]

guten morgen

ich denke, ich habe den fehler weiter einkreisen können.
(im anhang finden sie eine protoq)


habe mal alle datenbankdateien, die drumherum liegen; als da wo der fehler passierte (ald_172/173), extra 
genommen, und zusammen (2-stufig) indexiert. und siehe da qrix wird etwas geschwätziger:

die vielen ladefehler sind relativ normal, sie entstehen durch merkwürdige steuerzeichen, die in wenigen 
datensätzen verblieben sind (z.b. das pipe-zeichen); deshalb bildet er auch z.b. den INDEX64 ab. egal. 


aber mittendrin:

Ladefehler 22, fehlerhafter Schlüssel =>|castelao, daniel -> castelao, alfonso r
odriguez<,
  (voriger=> der Initialisierung von COMMAND.COM trat ein kritischer
Fehler auf dem Datenträger auf. Die Verarbeitung kann nicht fortgesetzt
werden. In dieser Sitzung sind keine weiteren Aktivitäten möglich. Die
Sitzung schließen und eine neue Sitzung starten. Kann COMMAND.COM wieder
nicht gestartet werden, ist der Kundendienst zu benachrichtigen.
$§
<), Satznummer = 422391794

Ladefehler 22, fehlerhafter Schlüssel =>|rodriguez castelao, alfonso -> castelao
, alfonso rodriguez<,
  (voriger=> 0
<), Satznummer = 422391794


WAS hat qrix dazu veranlasst, auszusteigen(?); aber gleich auch wieder einzusteigen?!


was passiert hier?
wer kennt den fehler?
wo ist er zu suchen? in der alg?




...
stunden später. ich habe mal diese mail auf eis gelegt. und weiter experimentiert.
dank des herrn castelao (s.o.) bin ich auf zwei inhalte gestossen, die merkwürdig sind:

in obiger ald ist ein satzinhalt wie folgt:
pipe_p_pipe (=3 zeichen: alt124-buchstabe_p-alt124). 
dieser satzinhalt kommt desweiteren auch noch in einer der letzten ald's, die dann noch später zu indexiern 
sind, vor. ich kann mich erinnern, daß diese unglückselige kombination ganz früher mir schon mal 
kopfzerbrechen bereitet hat. in einigen mab-dateien aus der deutsch.bibliothek habe ich das früher(?) mal 
gesehen.


...
weitere stunden später.
auch wenn ich diese o.g. pipe-inhalte rausnehme, so geschieht später bei der indexierung imemr noch etwas 
merkwürdiges:

qrix mag die datei 173 nicht zu ende mischen. c-tree error 235 kommt. /es gibt keinen hinweis in der protoq, 
diese notiert NICHT den c-tree-error235!/ . die datenbank ist ab der datei dbc_173.ald nicht weiter zu 
indexieren.

die platte ist noch zu 50% leer /oder zu 50% voll ;-) /
ABER: die datenbank hat eine GESAMTgroesse erreicht von : 2.329M bytes in 69 selected files
hat DAS was zu sagen? ist das nicht vergleichbar mit der GB-grenze beim alten dos?
ist in qrix (oder index?) eine 2GB-bremser aus alten zeiten eingebaut/übriggeblieben?

nehme ich die letzten 20 ald's (darunter 172 und 173) extra, und indexiere sie separat, gibts eine schöne 
brauchbare datenbank. ist das ein hinweis auf eine von mir vermutete 2GB grenze?
(wen's interessiert, im anhang _dir.txt;  mit directory abbbild der datenbank)


ist denn HIER jemand, der mal über die 2GB grenze gekommen ist?


etwas ratlos
viele sonntägliche grüße
ihr
k.lehmann





-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : protoq
Dateityp    : application/octet-stream
Dateigröße  : 12033 bytes
Beschreibung: nicht verfügbar
URL         : <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20040905/770a81b7/attachment.obj>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : _dir.txt
Dateityp    : application/octet-stream
Dateigröße  : 3855 bytes
Beschreibung: nicht verfügbar
URL         : <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20040905/770a81b7/attachment-0001.obj>