Defekte Indexfiles

[saul]

Hallo,
in einen Programm nutze ich folgenden Indexaufbau im DBFNTX System:

Code: Alles auswählen

use lfz_zeit exclusive   	// öffnet exclusiv
  index on typ+kennzeich TAG ("ztypken") to lfz_ztyp

  index on upper(kennzeich)+upper(gruppe)+upper(bezeich) TAG ("zkezgrubez") to lfz_zken

  index on kennzeich+gruppe+pn TAG ("zkezgrupn") to lfz_zkgp

  index on kennzeich TAG ("zkez") to lfz_zku

  set unique on
  index on bezeich+gruppe TAG ("zbezgruken") to lfz_zbef
  set unique off

  index on bezeich+gruppe TAG ("zbefbezgru") to lfz_zbeb

  index on befvornr TAG ("zbefvornr") to lfz_zben       	

  set unique on
  index on typ+kennzeich TAG ("mastypken") to lfz_ztk
  set unique off

  index on bezug TAG ("zeitbezug") to lfz_zbez	

  index on upper(kennzeich)+upper(substr(gruppe,1,4))+upper(bezeich)+upper(substr(gruppe,5,2)) TAG ("lfzliste") to lfz_zlis

use  lfz_zeit shared     //öffnet nicht exclusiv
set index to lfz_zken, lfz_ztyp, lfz_zkgp, lfz_zku, lfz_zbef, lfz_zbeb, lfz_zben, lfz_ztk, lfz_zbez, lfz_zlis

Jahrelang ist das System einwandfrei gelaufen. Nun habe den letzten lfz_zlis.ntx Index neu hinzugemacht. Seither gibt es manchmal Probleme mit der Sortierung. Lösche ich dann den Indexfile lfz_zlis.ntx und lasse ihn wieder neu aufbauen ist das Problem erstmal wieder weg. Leider kann ich keine Regelmäßigkeit geschweige die Stelle erkennen an der der Fehler durch das Programm auftritt.

Hat einer eine Idee?

mfg
Wolfgang

[Tom]

Häufigste Ursache solche Probleme ist, dass an irgendeiner Stelle die Tabelle mit Indexen geöffnet wird, aber mindestens einer vergessen wurde. Löscht, ergänzt und/oder ändert man dann einen Datensatz, fehlen die entsprechenden Informationen im Index, und es kommt zu Fehlern. Zuweilen geschieht das, wenn man später Code nachträgt, der auch nur selten bei der Anwendung angefasst wird, so dass der Fehler nur hin und wieder auftritt. Also: Alle Stellen prüfen, an denen diese Tabelle verwendet wird, und Indextabelle kontrollieren.

[brandelh]

Läuft das auf einem Rechner oder im Netzwerk ?

Bei letzterem, welche Betriebssysteme haben der Server und die Clients ?

10 Indexe gleichzeitig sind schon aufwändig (jede muss bei jeder Satzbewegung gesperrt werden), du solltest über DBE_LOCKMODE LOCKING_EXTENDED nachdenken => NTX DBE

[saul]

Hi,
ja das ganze läuft im Netztwerk, W Home Server 2011 mit W7 Clients. Die Virenscanner hatte ich auch in Verdacht, konnte denen aber bishe noch nix nachweisen.

DBE_LOCKMODE LOCKING_EXTENDED werde ich mir mal anschauen.

mfg
Wolfgang

[brandelh]

du mußt mindestens 3 Schalter setzen, bei Alaska gibt es auch eine Datei dafür.
Es geht um CACHE Einstellungen von Windows 7 ...

[brandelh]

Schau diesen Thread an, gleiches Problem, habe ich auch, aber ich kann nicht einfach bei uns die Einträge setzen

http://www.xbaseforum.de/viewtopic.php? ... t=0#p72023

Nochwas, es ist besser auf Netzwerkdateien per UNC Name zuzugreifen statt den Pfad einem Buchstaben zuzuordenen: \\server\freigabe\pfad\datei

Jimmy hat das empfohlen in einem anderen Thread

[AUGE_OHR]

hi,

ich tendiere zur selben Meinung wie Tom das nicht "immer alle zugehörigen Indexe" geöffnet wurden ... was am Programmierer Style liegt !
Warum nicht eine Function NET_USE() nutzen, wo man ja auch die Netzwerk Funktionen integriert hat wie NetErr(), um "dort" auch die zugehörigen Indexe zu öffnen ?

W Home Server 2011 mit W7 Clients.

hm ... wie ich sehe basiert Vail schon auf dem Windows Server 2008 R2 und nicht wie vorher auf dem W2K3.
somit ist es also möglich das man als Client in Heimnetzgruppen unter Windows 7 beitreten kann was beim alten WHS nicht möglich war.

ich hab allerdings selbst noch nicht damit gearbeitet da es ja zusammen mit einer Hardwarelösungen als Systembuilder für OEM angeboten wird und ich mit NAS nichts am Hut habe. Die Frage wäre also "was" der Unterschied zu einem "echten" W2K8R2 Server ist ... ausser der Preis ...

die alte WHS Version war stark beschnitten in der Userverwaltung und die CAL war auf 3 ( oder 5) begrenzt ...

Code: Alles auswählen

use lfz_zeit exclusive      // öffnet exclusiv
  index on typ+kennzeich TAG ("ztypken") to lfz_ztyp
...
  index on upper(kennzeich)+upper(substr(gruppe,1,4))+upper(bezeich)+upper(substr(gruppe,5,2)) TAG ("lfzliste") to lfz_zlis

ich sehe es immer wieder das "zwischen" den INDEX ON kein CLOSE INDEX genutzt wird ... hm ...


Frage : wie lang ist der IndexKey() des letzten TAG ("lfzliste") ?
ist bei "gruppe" sicher das der String so lang ist ?

warum so "viele" UPPER ?

Code: Alles auswählen

index on upper( kennzeich+substr(gruppe+SPACE(4),1,4)+bezeich+substr(gruppe+SPACE(7),5,2) ) TAG ("lfzliste") to lfz_zlis
CLOSE INDEX

da reicht doch 1 x UPPER() aus ?!

Code: Alles auswählen

  set unique on
  index on ...
  set unique off

Frage : sind da DELETED Records dabei ?
ich habe das "Gefühl" das UNIQUE bei vielen DELETED nicht lange / sicher funktioniert ...
ein Grund warum nach dem Backup immer noch ein reINDEX ( neu aufbauen ) erfolgt wenn NTX ( meisten noch mit Cl*pper ) verwendet wird.

[saul]

Guten Morgen,
ich öffne alle Dateien sowie Indexe und schließe diese erst wieder wenn ich das Programm verlasse. Das Öffnen im Netz kostet doch immer wieder Zeit vor allem wenn die Dateien recht groß sind.

ich hab allerdings selbst noch nicht damit gearbeitet da es ja zusammen mit einer Hardwarelösungen als Systembuilder für OEM angeboten wird und ich mit NAS nichts am Hut habe. Die Frage wäre also "was" der Unterschied zu einem "echten" W2K8R2 Server ist ... ausser der Preis ...

Ich benötige den Server nur als Dateiablage und es hat den Vorteil dass ich mit meiner langsamen Internetverbindung den Server über Remote Programme als Arbeitspaltz nutzen kann um vom Haus drauf zu arbeiten. Da war der Homeserver vom Preis her unschlagbar.

Das mit den vielen upper() stimmt. Da kann man mal sehen wie blind man manchmal ist.

Hätte ein close index denn Vorteile?

mfg
Wolfgang

[AUGE_OHR]

Das Öffnen im Netz kostet doch immer wieder Zeit vor allem wenn die Dateien recht groß sind.

hm ... hast du KB150384 ? http://support.microsoft.com/kb/150384

Hätte ein close index denn Vorteile?

Gegenfrage : wozu gibt es CLOSE INDEX ?
gerade weil du mit UNIQUE arbeitest würde ich eine "aktiven" Index erst schliessen bevor ich ein neuen Index aufbauen.

dein "Problem" wird aber, wie Tom schon sagte, vermutlich sein das nicht überall die DBF mit "allen" Indexen geöffnet wird.

[brandelh]

Ich tippe eher auf Netzwerkprobleme

Es kann nicht sein, dass INDEX ON von andereren Indexdateien abhängig ist.
Bei NTX wird sicherlich der aktive sogar dicht gemacht. (habe ich jetzt aber nicht probiert).
Nur bei CDX kann man einen neuen Index als TAG hinzufügen, wenn schon einer offen ist braucht man die Datei nicht angeben.
Das bedeutet aber, dass man selbst die Indexe nicht schließen muss, wenn ein neuer erzeugt wird.

[AUGE_OHR]

Ich tippe eher auf Netzwerkprobleme

jaja ... die Hardware ...

Nur bei CDX kann man einen neuen Index als TAG hinzufügen, wenn schon einer offen ist braucht man die Datei nicht angeben.

es "könnte" mit dem TAG zusammenhängen, den es bei Cl*pper für NTX nicht gibt.

Das bedeutet aber, dass man selbst die Indexe nicht schließen muss, wenn ein neuer erzeugt wird.

aber auch nicht das es ein Nachteil ist es so wie unter Cl*pper zu handhaben und CLOSE INDEX zu verwendet.

[brandelh]

aber auch nicht das es ein Nachteil ist es so wie unter Cl*pper zu handhaben und CLOSE INDEX zu verwendet.

da hast du natürlich Recht, ich meine nur er soll sich keine Hoffnung machen, dass sein Problem durch CLOSE INDEX gelöst ist

PS: Bei mir haben Sie erneut versucht die Registry Schalter zu setzen, aber der Server hat nur einen akzeptiert, kein Mensch (hier) weiß warum ...

Hier nochmal die Keys (ich hoffe ich mache jetzt keinen Fehler ):

Windows XP Clients:

\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters\OplocksDisabled = 1 // DWORD
\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters\InfoCacheLevel = 16 // DWORD dezimal Wert, Hex 10

Windows 2003 Server oder XP Client, der Dateien anbietet:

\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\EnableOplocks = 0 // DWORD

Ab Windows 7 (Vista) auf Client Rechnern:

\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\FileInfoCacheLifetime = 0 // DWORD
\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\FileNotFoundCacheLifetime = 0 // DWORD
\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\DirectoryCacheLifetime = 0 // DWORD

[Tom]

Es ist selten die Hardware. Ungewöhnliche Netzwerklatenzen o.ä. weisen durchaus auf krüppelige Router oder miese Verkabelung hin (wobei es die ja sehr toleranten Protokolle zumeist trotzdem noch schaffen, korrekte Datenpakete zu übertragen), aber ein Rechner, der etwas so Komplexes schafft wie Windows zum Laufen zu bringen, dürfte auch überwiegend in Ordnung sein. Die meisten Probleme dieser Art sind erfahrungsgemäß hausgemacht. Tabelle mit Indexen geöffnet, einen vergessen, derlei. 98 Prozent, würde ich mal grob schätzen.

[brandelh]

auf jeden Fall ist es eine gute Idee all die kleinen USE ... durch eine einzige Funktion zu ersetzen die die Dateien öffnet, möglicherweise mit Parameter welche man haben will
So kann man sicher sein, dass immer alle Indexe offen sind und auch die Reihenfolge stimmt.