zerstörte DBF
Dieter Tautz
Ich kämpfe noch immer mit folgendem Problem:
Datenbank befindet sich im Netz (windows Server 2008 SP2). Auf dem Client
läuft Windwos 7. Oplock ist abgeschaltet (Server + Client). Ich habe eine
Tabelle, bei der zwei Tabellenfelder vom Typ integer indexiert sind (jeweils
einfacher Index). Die Indexdatei ist eine CDX.
Nach dem Anfügen von Datensätzen mit "Insert into ... from memvar" erhalte
ich sporadisch (d.h. nicht bei jedem Insert) eine zerstörte DBF. Nach einem
reindex ist aber wieder alles in Ordnung. In Verbindung mit einem XP-Client
habe ich dieses Verhalten bisher (noch) nicht festgestellt. Hat jemand eine
Idee, wie man sich hier systematisch an die Ursache rantasten kann ?
Dieter
Olaf Doschke
Im laufenden Betrieb ist es schwierig.
Das SMB2 Protokoll hast Du ja quasi schon als Grund ausgeschaltet.
Aber auch wenn dieselbe Hardware unter XP fehlerfrei l�uft, k�nnte
es am Netzwerk und der Netzwerkhardware liegen, z.B. mangelhafte
Vista/2008 SP2/Win7-Treiber.
Um das auszuschlie�en m��te man die VFP Datenbank mal zu einem
Client bringen, wobei das nat�rlich nicht nur das Netzwerk, sondern
auch andere Clients ausschaltet.
Dann vielleicht mal einen Linux-Fileserver mit Samba aufbauen und sehen
ob ein anderer Server einen Unterschied ausmacht bringt.
Protokollieren sollte auch helfen, insbesondere von welcher Station
in welche Tabelle was gespeichert werden soll, bevor das Tableupdate()
kommt.
Hast Du schon TABLEVALIDATE auf 11?
Und reagierst Du auf Error 3 und 108? Wie?
Machst Du RETRY aus dem Errorhandler heraus? Machst Du ROLLBACKs
von Transaktionen, wenn TXNLEVEL()>0 vor einem QUIT oder CANCEL
im Errorhandling?
Da Du alles in einer, der generellen Datasession aufmachst, hast Du ein
und dieselbe Tabelle �fter mal unter verschiedenen Aliasen offen? U.u. hast
Du dann immer die Korruption, wenn die Tabelle in 2 Aliasen auf
verschiedenen St�nden ist? Machst Du SYS(1104) nach Transaktionen/
Speichern?
Tsch��, Olaf.
Jürgen Wondzinski
ich raffs immer noch nicht, was eigentlich bei dir wirklich kaputtgeht. Da
hilft auch nicht, nen neuen Thread anzufangen.... Am Anfang meintest du,
dass die CDX kaputt wäre. Nun ist es
>> eine zerstörte DBF.
>> Nach einem reindex ist aber wieder alles in Ordnung.
Ein REINDEX repariert keine DBF !
--
wOOdy
Visual FoxPro Technologieberater
Microsoft "Most Valuable Professional" 1996 bis 2009
"*´¨)
¸.·´¸.·*´¨) ¸.·*¨)
(¸.·´. (¸.·` *
..·`.Visual FoxPro: It's magic !
(¸.·``··*
Olaf Doschke
>>> Nach einem reindex ist aber wieder alles in Ordnung.
>
> Ein REINDEX repariert keine DBF !
Es scheint sich hier allein um Indexdefekte zu handeln.
Und sofern die Indexausdr�cke im CDX-Header okay sind,
regeneriert der REINDEX die CDX-Datei schon.
Die DBF wird damit �berhaupt nicht angefa�t, das ist richtig.
Ich meine Aleksey Tsingauz hatte doch mal etwas bez�glich
Problemen vom Caching von Indizes im Mukltiuserbetrieb
bei UT gepostet.
@Dieter:
Eine Frage ist mir bis Dato unbeantwortet: Woran machst Du
den Defekt fest? Bekommst Du einen Fehler bei Nutzung der
DBF? Bei Nutzung eines Indexes? Wenn ja, welchen?
Oder wird einfach nur etwas nicht im Index gefunden?
Tsch��, Olaf.
Dieter Tautz
Den neuen Thread habe ich angefangen, weil das Problem offensichtlich mit
Oplock nichts mehr zu tun hat.
Eine DBF ist für mich "zerstört", wenn ich mit der Tabelle nicht mehr
arbeiten kann. Die Ursache dafür versuche ich gerade herauszufinden. Nach
meinem Kenntnisstand wird bei einem USE die Indexdatei (CDX) automatisch mit
geöffnet. Wenn es dann also Probleme mit der Tabellenverarbeitung gibt, kann
dies doch durchaus an der CDX-Datei liegen. Es fehlen ja am Ende auch keine
Datensätze. Nur kann ich manche Datensätze erst nach einem reindex wieder
"ansprechen".
Von Olaf habe ich ja einige Hausaufgaben bekommen. Dies werde ich Schritt
für Schritt abarbeiten. Ich hoffe damit das Problem zumindest eingrenzen zu
können.
Dieter
Olaf Doschke
Mach doch mal bitte folgendes zu den zu einem Defekt neigenden Tabellen:
CREATE CURSOR curTaginfo (cTagname C(10), cTagtype C(10), cKeyExpression
C(254), cFilterexpression C(254), cIndexOrder C(4), cCollate C(20))
SELECT 0
USE DeineTabelle
INSERT INTO curTagInfo (cKeyExpression,cCollate) Values (DBF(), CPDBF())
IF ATAGINFO(laTags)>0
APPEND FROM ARRAY laTags
ENDIF
COPY TO ...txt TYPE CSV
und dann poste doch mal den CSV-Dateiinhalt.
Tsch��, Olaf.
Dieter Tautz
"Olaf Doschke" wrote:
> Eine Frage ist mir bis Dato unbeantwortet: Woran machst Du
> den Defekt fest? Bekommst Du einen Fehler bei Nutzung der
> DBF? Bei Nutzung eines Indexes? Wenn ja, welchen?
1. Datensätze werden doppelt an verschiedenen Stellen im Grid angezeigt -
dafür fehlen andere. Nach einem reindex werden alle Datensätze in der
richtigen Reihenfolge angezeigt.
2. INSERT ist nicht möglich.
Dieter
Olaf Doschke
> 1. Datens�tze werden doppelt an verschiedenen Stellen im Grid angezeigt -
> daf�r fehlen andere. Nach einem reindex werden alle Datens�tze in der
> richtigen Reihenfolge angezeigt.
Wie ist in dem Momen CPCurrent und welchen Index nutzt Du zur Sortierung?
> 2. INSERT ist nicht m�glich.
Wie �u�ert sich das? Fehlernummer?
Tsch��, Olaf.
Dieter Tautz
Hier der CSV-Inhalt:
ctagname,ctagtype,ckeyexpression,cfilterexpression,cindexorder,ccollate
,"","N:\PROGRAMME\4G_PASSIV\DATA\GENRKAP.DBF","","","1252"
VERTRNR,"EINFACH","NVERTRNR","","AUFS","GERMAN"
BUCHNR,"EINFACH","NBUCHNR","","AUFS","GERMAN"
Dieter
Olaf Doschke
also einfach indezes in german collation auf einzelne Felder. Aber warum
deutsch "AUFS"TEIGEND? Welche Runtime benutzt Du da? Machst Du das in der
IDE oder in der compilierten Anwendung?
Unter VFP9 sollte an der Stelle im ATAGINFO array "ASCE"NDING oder
"DESC"ENDING stehen.
Mal abgesehen davon ist das "ungewöhnlichste" an diesen Indizes die deutsche
Collation, aber mir ist kein Bug bekannt, weswegen die Collation dazu führen
würde, daß die Indizes nicht mitaktualisiert werden.
In Deinem Grid mit den Lücken, nutzt Du da in dem Moment wirklich zur
Sortierung einen dieser Indizes? Oder wird der Gridinhalt mit SQL ORDER BY
selektiert und angezeigt? Bei letzterem spielt die aktuell eingestellte
COLLATING Sequenz eine Rolle.
Wenn Datensätze angefügt wurden, bleibt dann wirklich der CDX auf dem alten
Datumsstand und nur an der DBF ändert sich das Dateidatum?
Tschüß, Olaf.
Dieter Tautz
Ich habe gerade wieder per Programmroutine mit INSERT Datensätze angefügt.
Kurz vor Schluß meldete sich die ON-ERROR-Routine mit der Meldung "Die
Indexdatei '.....' tag '....' ist beschädigt. Erstellen Sie die Datei neu".
In der Programmroutine mache ich nicht explizit nach jedem INSERT ein
Tableupdate(). Sollte man das tun?
Das Programm lief in vorliegender Fassung seit Jahren stabil. Ich habe
diesmal auch nicht den Windows7-Client verwendet. Bliebe als einzige Änderung
an der Systemumgebung das SP2 von Windows Server 2008.
Dieter
Dieter Tautz
> Machst Du das in der IDE
Ja. VFP 9.0 SP2 deutsche Lokalisierung.
> In Deinem Grid mit den Lücken, nutzt Du da in dem Moment wirklich zur
> Sortierung einen dieser Indizes?
JA
> Wenn Datensätze angefügt wurden, bleibt dann wirklich der CDX auf dem alten
> Datumsstand und nur an der DBF ändert sich das Dateidatum?
Datumsstand von DBF und CDX sind identisch.
Dieter
Olaf Doschke
> In der Programmroutine mache ich nicht explizit nach jedem INSERT ein
> Tableupdate(). Sollte man das tun?
ein Tableupdate() ist dazu da, Daten aus einem Buffer in die DBF zu
schreiben. Ein Insert-SQL schreibt per Definition sofort in die DBF.
Insofern ist ein Tableupdate() dabei nicht sch�dlich aber auch nicht
n�tzlich.
N�tzlich w�re ein SYS(1104) nach einem INSERT oder Tableupdate().
Mit einem Mix aus Arbeiten im Buffer und mit INSERTS oder auch UPDATEs und
DELETEs schafftst Du sogar im einzelnen Prozess schon eine
Multiuserzugriffs-Situation auf die DBF. Wobei INSERTS vorbei am DBF-Buffer
da noch am wenigsten st�rend sind, weil sie den Buffer ja nicht invalide
machen, wie es ein UPDATE oder DELETE tun k�nnte. Allerdings wird auch durch
einen Insert ein etwaiger gecachter Indexteil u.U. invalide Ein Index ist ja
nicht eine so flache Struktur wie ein DBF mit nacheinander abfolgenden
Records, sondern ein Tree mit Nodes. Ein Insert kann ein umh�ngen eines
Baumzweiges verursachen und damit gecachte Nodes invalide machen. Und ich
meine nach wie vor es gab zu dem Thema auch einen gr��eren Thread bei UT,
ich hab da auch schon mal ein Viertelst�ndchen in Suchen investiert aber
nichts gefunden.
Ich sch�tze Du hast nur indirekte M�glichkeiten, diese Indexdefekte zu
vermeiden. U.U. ist einfach nur eine Diskrepanz zwischen dem evtl. sogar
korrekt durch eine Arbeitstattion erweiterten CDX und dem, was eine andere
Arbeitsstation, die den Indexdefekt anmeckert, im Cache hat.
Deswegen, und nicht nur weil jede zus�tzliche Information, die man so hat
zur Analyse eines Problem beitragen kannm, w�re f�r mich so interessant, ob
sich bei der CDX-Datei eine Diskrepanz zwischen dem �nderungsdatum zum
�nderungsdatum der DBF ergibt.
Tsch��, Olaf.
Olaf Doschke
bedeuten, da� die Meldung �ber den Indexdefekt ein Fehlalarm ist. Wenn Du
wieder so einen Fall hast pr�fe doch mal, ob in einer frisch neu ge�ffneten
IDE der CDX so wie er ist doch funktioniert und vollst�ndig in Ordnung ist.
Hattest Du eigentlich au�er einem REINDEX auch mal probiert per DELTE TAG
ALL alle Indizes zu l�schen und danach komplett neu aufzubauen?
Tsch��, Olaf.
Dieter Tautz
> ALL alle Indizes zu löschen und danach komplett neu aufzubauen?
Nein, habe ich bisher noch nicht.
Dieter Tautz
>U.U. ist einfach nur eine Diskrepanz zwischen dem evtl. sogar
> korrekt durch eine Arbeitstattion erweiterten CDX und dem, was eine andere
> Arbeitsstation, die den Indexdefekt anmeckert, im Cache hat.
Die Meldung bezüglich der defekten Indexdatei habe ich ja selbst während der
Insert-Routine bekommen. Kann die Größe der DBF's eine Rolle spielen (17 MB
bzw. 42 MB) ?
Dieter
Olaf Doschke
> der
> Insert-Routine bekommen. Kann die Gr��e der DBF's eine Rolle spielen (17
> bzw. 42 MB) ?
Okay, nichtsdestotrotz ist das eine Meldung eines Defektes, was nicht hei�t,
da� der Defekt dort entsteht.
Die Insert-Routeine mach aber die SQL-Inserts, richtig? Vielleicht postest
Du mal den Code.
17 bzw. 42 MB sind nichts sonderlich gro�es. Es gibt nur ein 2GB limit,
davon bist Du weit entfernt.
Tsch��, Olaf.
Dieter Tautz
Ich habe Dich nicht vergessen, aber ich war zwei Tage nicht in der Firma. Im
Moment gibt es auch eigenartigerweise keine Probleme (ich sollte öfters fern
bleiben). Ich habe jetzt noch einiges am Programm verändert
(Protokollfunktion, Sys(1104), ...) und werde die Sache weiter verfolgen.
Sollte der Effekt wieder auftreten, hoffe ich dann etwas detaillierte
Informationen liefern zu können.
Vielen Dank für Deine Geduld
Dieter
Christoph Dre�ler
bei solchen Dateigr��en haben wir auch gelegentlich defekte Indexe.
Ursache ist letztlich die Sensibilit�t des Fuchses auf Wackligkeiten
im Dateisystem (Netz-Hard/Soft, Virenscanner usw.).
Wirklich Ruhe hast Du bei gr��eren Datenmengen bze. Traffic nur bei
Nutzung eines SQL Servers.
-christoph
Jürgen Wondzinski
>> die Gr��e der DBF's eine Rolle spielen (17 MB bzw. 42 MB) ?
> bei solchen Dateigr��en haben wir auch gelegentlich defekte Indexe.
Huh? Du betrachtest mickrige 42 Mb als problematisch? Ich hab hierbei nem
Kunden Dateien, die momentan knapp 1Gb gross sind, und im Dauereinsatz von
15 Usern bearbeitet werden. Das Ganze in einem alten 100MBit Netzwerk.
Wichtig ist heutzutage nur, dass man auf Laptops ein Auge wirft, die per
WLAN unterwegs sind. WLANs sind bekannt f�r gelegentliche
Verbindungsabbr�che, und damit Verursacher von nicht ordentlich
geschlossenen Tabellen.