Probleme mit Erstellen von .NTX

[AUGE_OHR]

hi,

Cl*pper Help File
TEMPPATH:'<path>' controls the placement of temporary files created
during sorting and indexing. By default these files are placed in
the current DOS directory or in the directory specified by the SET TMP
environment variable, if it is defined.

Note: Temporary files created during sorting and indexing can be quite
large. Setting TEMPPATH to a small volume (for example, a ram disk) may
cause these operations to fail. In general, the volume where these
temporary files will be written should have an available capacity at
least twice the size of the largest index to be created or database file
to be sorted.

ich hatte damals beim booten die Command.COM auf eine RAM-Disk kopiert und COMSPEC auf die RAM-Disk geleitet.
irgendwann wollte ich dann auch die "anderen" Environment Variabeln auf die RAM-Disk "umleiten" ...

Umgebungsvariablen Xbase++

TMP=<Verzeichnis>

Im TMP Verzeichnis werden temporäre Dateien angelegt, z.B. wenn INDEX ON oder DbSort() ausgeführt wird.

hast du die Umgebungsvariable TMP gesetzt ?
User (Schreib) Kontingent ?

[UliTs]

Hallo Herbert,

hast Du mal ein kleines Testprogramm geschrieben, welches eine DBF-Datei anlegt und anschließend einen Index dazu?
Also: keine einzige Zeile Quellcode aus Deinem eigentlichen Programm!
Tritt dann der Fehler auch auf?

Uli

[Herbert]

Hallo Jimmy
Leider kann ich beim Kunden nicht auf die Innereien der PC zugreifen.
Den tmp-Pfad werde ich nachsehen.
Uli, nein. Weil dasselbe Programm bei auf allen anderen Installationen (gegen 80) problemlos klappt.
Muss mich dann wohl so zwei, drei Stunden beim Kunden einschleusen.

[brandelh]

Wenn die Indexdateien futsch sind, stürtzt dann das Programm mit xppfatal.log oder xpperror.log ab ?
Wenn nein ... kann man an der Dateigröße erkennen, dass diese z.B. auf 0 steht oder sehr klein ist ?

Was es alles gibt ...

[UliTs]

Hallo Herbert,

Uli, nein. Weil dasselbe Programm bei auf allen anderen Installationen (gegen 80) problemlos klappt.

Dessen war ich mir bewußt. Ich dachte, Du lässt das Testprogramm bei den 2 Testkunden laufen, um zu sehen, ob der Fehler dann auch auftritt (wovon ich ausgehe) und um dann mit dem Testprogramm zu experimentieren.
-
Interessant fände ich, ob bei dem Mini-Programm

Code: Alles auswählen

DBCreate(...)
Use ...
Index On ...
DbClose()
QUIT

auch anschließend der Index kaputt ist.

Uli

[Rolf Ramacher]

Hallo herbert,

ich würde das kleine Testprogramm mal beim Kunden ausprobieren, um zu sehen, ob dieser Rechner generell Probleme hat die ntx.Datei zu erstellen.

[ramses]

Hi

Wieviele Zeichen hat dein Dateinamen der Indexdatei?

so was in der Form hatte ich auch mal, seit dem verwende ich max. 8 Zeichen für den Dateinamen ohne Enthaltene Leerzeichen und öäü, und im Funktionsaufruf von DBCreateIndex() keine Arrays mehr, seit dem ist das Problem nie mehr aufgetreten.

Zudem ist es empfehlenswert vor DBCreateIndex() zuerst zu Prüfen dass die Datei wirklich gelöscht ist und bei der Verwendung von Pfaden immer auch den LW Buchstaben verwenden-


Gruss Carlo

[Herbert]

Wenn die Indexdateien futsch sind, stürtzt dann das Programm mit xppfatal.log oder xpperror.log ab ?
Wenn nein ... kann man an der Dateigröße erkennen, dass diese z.B. auf 0 steht oder sehr klein ist ?
Was es alles gibt ...

Nein, das Programm sürzt nicht ab, es kommt bei jedem Seek auf EOF()

Die Dateigrösse sieht "vernünftig" aus (die Grösse ist gleich, wie wenn das .NTX mit DBU erstellt wurde).

[Herbert]

Wieviele Zeichen hat dein Dateinamen der Indexdatei?

Zudem ist es empfehlenswert vor DBCreateIndex() zuerst zu Prüfen dass die Datei wirklich gelöscht ist und bei der Verwendung von Pfaden immer auch den LW Buchstaben verwenden-

Ich achte stets auf kleine Dateinamen (Steffens Hinweise sind da treffend) stets ohne Umlaute. Auch der Pfad enthält nichts dergleichen.

Die Datei ist gelöscht. IF FILE(...) gibt .F. retour.
Auch steht in den Variablen für den Pfad immer das Laufwerk (oder der Netzwerkpfad beginnend mit \\)

[ramses]

Hallo Herbert

da bin ich mit meinen Erfahrungen auch am Ende.

Aus Verzweiflung würde ich mal noch auf UNC Pfade (\\...) verzichten
oder die Datei des Kunden mit einem Hex_Editor darauf prüfen ob allenfalls zerschossende Sectoren mit Datenmüll drin sind
oder ein Test mit einer Backupdatei(aus der Zeit als es noch ging) des Kunden erneut ausführen.

Den mit den zerschossenen Sectoren hatte ich mal, mit DBU sah die Datei gut aus jedoch beim Suchen oder Indexieren gabs Probleme leider schon lange her, die genaue Erscheinung hab ich vergessen.....

Gruss Carlo

[brandelh]

Code: Alles auswählen

          INDEX ON hinr  TAG "hinr"   TO (cpath+aInd[i])  

da es ja bei anderen funktioniert, hat es hiermit wahrscheinlich nichts zu tun, aber laut Handbuch:

TAG <cTagName>

Das optionale Argument <cTagName> gibt den Namen des Index an, der erzeugt werden soll. Es ist entweder ein Literal oder ein Zeichenausdruck in ()-Klammern. Ein Index kann über diesen Namen ausgewählt werden, so daß es nicht erforderlich ist, die genaue Position des Index' in der Liste offener Indizes zu kennen (Vergleichbar mit dem Alias-Namen einer Workarea). Die Länge von <cTagName> ist durch die DatabaseEngine vorgegeben, die den Index verwaltet.

müsste es entweder

Code: Alles auswählen

 INDEX ON hinr  TAG hinr   TO (cpath+aInd[i])  

oder

Code: Alles auswählen

 INDEX ON hinr  TAG ("hinr")   TO (cpath+aInd[i]) 

heißen

[Koverhage]

Herbert,

wenn Du sagst das die Dateigröße passt (gleich DBU und dort werden die Daten gefunden)
kann es nur an Deinem Schlüssel liegen.
Das Problem hatte ich auch: Irgendwo im Schlüssel bzw. Aufruf von Index on war ein Fehler
drin. Die Indexdatei wurde erstellt aber gefunden wurde nichts.

Was zeigt DBU dir denn als Index-Ausdruck an ?

[ramses]

Herbert

hast du mal versucht den Index mit DBU zu erzeugen?


Gruss Carlo

[Herbert]

Hubert: danke, weider einmal hast du ein Detail gefunden. Werde den Tag bei den .NTX wegnehmen. Brauche ich da nicht.
Interessant ist, dass bei OrdCreate der Tagname eine Zeichenkette ist. Ich hatte es von da her abgeleitet gehabt.

Herbert,

wenn Du sagst das die Dateigröße passt (gleich DBU und dort werden die Daten gefunden)
kann es nur an Deinem Schlüssel liegen.
Das Problem hatte ich auch: Irgendwo im Schlüssel bzw. Aufruf von Index on war ein Fehler
drin. Die Indexdatei wurde erstellt aber gefunden wurde nichts.

Was zeigt DBU dir denn als Index-Ausdruck an ?

Den Schlüssel. Im einfachsten Fall wäre es die Kundennummer (kunr, ein numerisches Feld mit Länge 5).

Ich habe jetzt bei beiden Kunden auf CDX umgestellt. So gehts.
Werde später wenn mehr Zeit ist, das Problem nochmals beim Kunden vertiefen.

Besten Dank für die vielen Tipps und Hinweise, die mir auch sonst gute Gedankenanstösse gegeben haben.

[Martin Altmann]

Moin Herbert,

Im einfachsten Fall wäre es die Kundennummer (kunr, ein numerisches Feld mit Länge 5).

ich will mal hoffen, dass Du den index nicht numerisch hast, sondern als str( kunr, 5 ) oder strzero( kunr, 5 ).

Viele Grüße,
Martin

[brandelh]

Hallo Martin,

solange man NUR ein numerisches Feld hat, ist ein numerischer Index kein Problem, das habe ich dauernd und keine Probleme mit NTX Dateien.

[Herbert]

Moin Herbert,

Im einfachsten Fall wäre es die Kundennummer (kunr, ein numerisches Feld mit Länge 5).

ich will mal hoffen, dass Du den index nicht numerisch hast, sondern als str( kunr, 5 ) oder strzero( kunr, 5 ).

Viele Grüße,
Martin

Wieso sollte das ein Problem sein?

[Martin Altmann]

Weil ich damit in der Vergangenheit häufiger immer wieder Probleme hatte!
Auch bei rein numerischen Feldern - ich habe dann auf str() umgestellt, seitdem ging es.

Viele Grüße,
Martin

[Herbert]

Nee, Index ist Index.
Der Schlüssel wird entsprechend umgesetzt. Aufgrund der Grösse des Schlüssels ist ein numerischer Index klein und daher sinnvoller (und wohl auch minim schneller).
Falls du Probleme damit hattest, musste das Problem ganz woanders gelegen haben.