"Fehler beim lesen" [Erledigt]

[Jan]

Ich browse durch eine dbf mit 2 Memofeldern. Dabei soll in Abhängigkeit davon, ob in diesen beiden Feldern etwas steht, etwas angezeigt werden. Dazu steht im oBrowse:stableblock diese Zeile drin:

Code: Alles auswählen

IIf(Empty(datenbank->notiz) .AND. Empty(datenbank->quelle)

Das hat immer funktioniert, aber plötzlich bekomme ich sporadisch diese fehlermeldung:

Sprachen-Version : 1.90.355
Betriebssystem :Windows 7 06.01 Build 07601 Service Pack 1
------------------------------------------------------------------------------
oError:args :
-> NIL
oError:canDefault : .F.
oError:canRetry : .T.
oError:canSubstitute: .F.
oError:cargo : NIL
oError:description : Fehler beim Lesen
oError:filename :
oError:genCode : 73
oError:operation : quelle
oError:osCode : 0
oError:severity : 2
oError:subCode : 8037
oError:subSystem : BASE
oError:thread : 1
oError:tries : 1

So eine Fehlermeldung ist mir noch nie untergekommen. Was will mir das sagen? Und was mache ich dagegen?

Jan

[AUGE_OHR]

oError:genCode : 73
oError:subCode : 8037
oError:thread : 1

ist es ein DBT Memo, wo du mit CDXDBF, zugreifen willst ?

8037 - [BASE] - ???
Associated with: "73:Error while reading a File"
Caused by: Access to memo field in "x.dbt" file (CDXDBF) on Windows XP
workstation and Novell Netware Server (opening the database
works without error, and the initial installation worked,
too, which also opened DBT files, and it also works on a
Windows 98 computer on the same network.

[Jan]

Ich habe inzwischen herausgefunden, das manche Einträge in den Memofeldern in irgendeiner Weise korrupt sind. Daher der sporadische Lesefehler.

Kennt jemand von Euch ein Reparaturprogramm für sowas?

Jan

[Wolfgang Ciriack]

Datensicherung zurückspielen ?

[Manfred]

Oder umkopieren,

das könnte aber dann weniger werden danach.

[Jan]

Manfred,

an umkopieren hatte ich auch schon gedacht. Aber wenn es dann beim Kopieren doch wieder einen Lesefehler auf dem Memofeld gibt?

Jan

[Manfred]

mit umkopieren meinte ich natürlich eine leere DBF und dann append from oder so. Aber dann werden defekte Sätze evtl. verschwinden.

[brandelh]

Hallo Jan,

du musst ein Programmschreiben, das Satzweise die Daten überträgt und Satzweise dokumentiert welcher Satz erfolgreich geschrieben wurde.
Nach einem Abruch überspringst du das fehlerhafte Feld und so weiter ...

[Jan]

So, hab das Teil "repariert". Etwas anders als vorgeschlagen, aber darauf basierend. Ich habe einfach die vorhandene Struktur eingelesen, eine neue dbf erstellt, und dann satzweise Feld für Feld rübergezogen. Dabei dieses satzweise kopieren in eine Errorschleife gelegt. Wenn also da ein Fehler passierte in einem der beiden Memofelder, dann hat der Errorblock das einfach abgefangen, und die Schleife lief weiter, als sei nix gewesen.

Vielen Dank für all die interessanten Tipps und Ratschäge.

Jan

[Scarmo]

Hallo Jan

Und wie verhält es sich mit der Performance? Ist es nun viel langsamer wie vorher oder ist der Zeitverlust vom satzweisen Kopieren vernachlässigbar?

Gruss
Marco

[Jan]

Marco,

der hat für gut 2.000 Sätze etwa 1 Sekunde gebraucht.

Jan

[AUGE_OHR]

hi

interessant wäre ja nun raus zu bekommen warum die Memo`s defekt sind.

sind es DBT oder FPT ? ... ich habe schon lange keine defekten Memo`s gesehen ...

[Tom]

Mmh.

Wir haben das im Zusammenhang mit Memo-Dateien derzeit auch recht intensiv bei einem Kunden, der unsere Software auf 2003/Server als Terminal-Server einsetzt. Es tritt auf, seitdem das OpLocking wieder eingeschaltet wurde, da das deaktivierte OpLocking dort zu einer erheblichen Entschleunigung führte. Ich habe die Tabellen geprüft und keine Fehler gefunden. Es gibt aber einen KB in der MSDN zu diesem Thema, allerdings für Windows Server 2000 (nebst Patch), nicht für den 2003er. Dort ist die Rede davon, dass der Server zuweilen eigenständig DBT-Dateien schließt/freigibt, wenn DBFs mit DBTs mehrfach geöffnet und von einem Benutzer wieder geschlossen wurden. Anders gesagt: X Benutzer haben eine DBF/DBT geöffnet, einer davon schließt, und jetzt gibt der Server alle Handles auf alle DBTs frei, schließt diese also für alle Benutzer. Dadurch entsteht dann beim nächsten Zugriff auf die DBT "Fehler beim Lesen", was wenig wundert. Ohne OpLocking tritt das Problem offenbar nicht auf, aber ohne aktiviertes OpLocking ist die Zugriffsgeschwindigkeit unzumutbar langsam. Übrigens haben wir andere Kunden mit sehr ähnlichen Topologien, und dort kommt es nicht zu diesen Fehlern (auch mit aktiviertem OpLocking).

[Jan]

Ich muß gestehen, das ich keine Ahnung habe, was da passiert ist. Von den gut 2.000 Datensätzen waren nur die Memfolder von 39 Sätzen korrupt, und von den beiden Memofeldern jedes Satzes auch immer nur eines. Alle anderen liefen einwandfrei, ebenfalls alle anderen Felder.

Ich arbeite schon ewig nur noch mit FoxCdx. Allerdings meist mit umbenannten Dateiendungen.

Jan

[AUGE_OHR]

hi,

eine Memo ist ja nur ein Pointer zu DBT / FPT Datei. Die FPT Structur findet man hier http://msdn.microsoft.com/en-us/library ... 71%29.aspx

nun hab ich mal bei Pablo im Newsforum angefragt

repair Memo with ot4xb ?
28. Dezember 2011

und eine Antwort von Pablo bekommen.

wenn ich das nun richtig verstehe kann man den "Zustand" der letzten Änderung eines Memo/Record wiederherstellen ( solange man kein PACK gemacht hat )
wenn ich eine Memo "ändere" wird wohl nicht der "bestehende" Platz "überschrieben" sondern an das Ende "angehängt" und die neue Position ( Pointer ) zurück geschrieben.

"wie" man nun aus seinem Template eine Application macht ... da muss ich wohl bei Pablo noch mal nachharken.

[Tom]

Ja, Memofelder werden beim erneuten Durchschreiben - bei DBT - angehängt, die alte Fassung bleibt erhalten. Anschließend wird in der DBF der Pointer aktualisiert - der eigentliche Inhalt des Datenbankfeldes mit dem Namen des Memofeldes. Aber das geschieht nach meiner Beobachtung unter Xbase++ nur dann, wenn der neue Inhalt des Memofeldes nicht in den Block/die Blöcke passt, die für die alte Fassung vorgesehen waren. Einfach mal ausprobieren! Unter dBase war das m.E. anders, da wurde immer neu geschrieben. Whatsoever, ich habe zwar mein "Handbuch der Dateiformate" nicht mehr, aber meiner Erinnerung nach endet jeder belegte Block (512 Bytes) in der DBT mit einem Pointer auf die Fortsetzung, wenn es eine gibt. So ähnlich arbeitet die FAT auch. Wird jetzt durch das Neuschreiben der Pointer aktualisiert, gibt es genau genommen keine Verbindung mehr zwischen dem Datensatz in der DBF und dem alten Eintrag in der DBT. Man kann ihn aber dennoch finden, wenn man weiß, wie er gelautet hat (Text). Das ist fummelig und lässt sich meiner Meinung nach auch nicht automatisieren (weil der alte Pointer weg ist), aber man kann mit einem Hex-Editor alte Memo-Inhalte zu Fuß wieder herstellen. Doch, wie gesagt: Nach meiner Prüfung schreibt Xbase++ nicht immer neu! Hat mich jetzt auch gerade verblüfft, aber es scheint tatsächlich so zu sein.

[AUGE_OHR]

... aber man kann mit einem Hex-Editor alte Memo-Inhalte zu Fuß wieder herstellen.

für den "010 HEX" Editor http://www.sweetscape.com/010editor/ ist wohl das Template von Pablo gedacht.

interessant bei dem Template ist ja die

Code: Alles auswählen

struct DBF {

welche die komplette DBF Structure beschreibt.
unser DBF System beruht also auf den selben Mechanismen wie Windows und das schon zu Zeiten von CP/M auf einem Apple ][

[brandelh]

Wie Tom schreibt,

dBase hat IMMER einen neuen Block angehängt, falls man das Memofeld geändert hatte.
Clipper und Xbase++ nutzen - wenn möglich - den alten Platz (wenn die Größe reicht),
ansonsten wird wieder hinten angehängt.
Das gilt für DBF/DBT, wie der FoxPro Treiber das macht weiß ich nicht.

Mein Problem mit DBF/DBT Dateien wurde vor zig Jahren lag sicher daran, dass
beim manuellen kopieren die DBF / DBT nicht mehr passten.
Warum, das lies sich nicht klären (Zugriff mit Explorer bei geshartem Laufwerk ...).

Bis es bemerkt wurde, waren jedoch schon viele Änderungen erfolgt, sodass man nicht
noch weiter zurück konnte.

PS: wenn es sich aber "nur" um das Problem handelt, dass die Datei vor dem Lesezugriff geschlossen wurde,
dann dürfte sie nicht defekt sein ! Defekt ist sie nur, wenn eine DBF auf einen nicht vorhandenen
MemoOffset zeigt. Übel ist es, wenn die DBF schon auf den neuen Eintrag zeigt, dieser aber
nicht mehr geschrieben werden konnte.