Fehler im dbu

[AUGE_OHR]

hm ... hat die DBF ein Memo ? Type "M" ? Länge 4 oder 10 ?

yep, 1 C "Name", 1 M "Text"

dann denke ich das dein Problem durch "defekte" Memo Felder auftritt ...

bei 83h hast du wohl eine DBT als Memo. ein Foxpro Memo hätte F5h und die FPT sind IMHO "stabiler".

... womit wir wieder bei der Frage wäre "wo" bei dir "was" passiert das es zu dieser Situation gekommen ist. ( OS() / Netzwerk ... )

[Alfred]

Was ich noch nicht kann, ist neue Felder hinzufügen, damit sie ansprechebar werden.

Datei/Struktur ändern

Gruß
Alfred

[AUGE_OHR]

Dann wäre bei der "defekten" Datei die Satzzahl belegt und bei der "funktionierenden" Datei die Satzzahl mit 0 drin??

0 oder irgendwas anderes was nicht mehr stimmt.
Hubert hat in der Wissenbasis einen Source veröffentlicht http://www.xbaseforum.de/viewtopic.php?f=16&t=2313

[Muecke]

Alfred

Mach mal eine neue Datenbank FOXCDX. Ich kann die Felder danach nicht sauber ansprechen.

Gruss Thomas

[brandelh]

Hi,

der DBU ohne Änderungen kann auch mit Xbase++ NUR DBFNTX Dateien verarbeiten !

[Tom]

Ich finde die Quellcodes für CL-DBU nicht, aber es mag möglich sein, dass es eine implizite Fehlerbehandlung gibt. Die dazu führt, dass im Fehlerfall beispielsweise Datensätze ignoriert werden, die korrupte Daten enthalten. Oder das Skippen hört an dieser Stelle auf. Es kommt darauf an, ob beispielsweise fehlerhafte Memofelder überhaupt angefasst werden. Das geschieht beispielsweise bei dem einfachen DBF-Browser, den man sich für Christian Ghislers "Total Commander" als Add-On installieren kann, nicht. Darin kann ich eine DBF browsen, zu der ich eine leere DBT einfach erzeugt habe, obwohl die Datensätze auf gefüllte Memofelder verweisen - das Tool ignoriert die Inhalte von Memofeldern einfach. Nehme ich mein eigenes Supertool, mit dem alle denkbaren Datei- und Wartungsoperationen möglich sind, und ich lasse mir diese Tabelle mit der gesetzten Option "Memofelder anzeigen" als Tabelle präsentieren, springt es im genannten Fall in meine Fehlerbehandlung (Feldinhalte werden nicht angezeigt - aber ich könnte dort natürlich auch entscheiden, den ganzen Datensatz zu ignorieren). Ohne die Option gibt es einfach keine Spalte für das Memofeld, und auch keinen Fehler.
Es gibt manchmal solche Situationen. Eine Memodatei ist irgendwie beschädigt, aber nicht alle Routinen laufen auch auf einen Fehler. Seltsamerweise gelingt es tatsächlich manchmal, mit einem einfachen COPY TO eine scheinbar instandgesetzte Fassung der Datei zu erzeugen (wirklich verlässlich ist das nicht), obwohl gerade hier die Memofelder ja angefasst werden müssen. Aber es mag auch sein, dass "DbExport" (die Funktion, auf die COPY TO letztlich verweist) auch mit einem rudimentären Errorhandling oder etwas Ähnlichem ausgestattet ist.

[brandelh]

Ich finde die Quellcodes für CL-DBU nicht, aber es mag möglich sein, dass es eine implizite Fehlerbehandlung gibt.

den Quellcode habe ich zwar, aber der ist sehr mühsam zu lesen

Ich habe folgendes gemacht:

1. TEST1.DBF mit DBT erzeugt (Feld 1 Text, Feld 2 Memo)
2. 4 Datensätze erzeugt, dbu zeigt Text normal an und "MEMO" im Memofeld.
3. DBU kopiert nach TEST2.DBx und ich lösche Satz 2 und Satz 4.
4. DBU kopiert mit ! deleted() nach TEST3.DBx
5. DOS copy TEST3.DBT nach TEST2.DBT
6. Xbase++ und Clipper 5.2e DBU öffnen die TEST1.DBF mit falscher DBT ohne Fehler.
7. Beide können auf Satz 1 und Satz 2 zugreifen (DBT Inhalt von aktuellem Satz 2 entspricht der Eingabe von Satz 3 !)
8. Xbase++ DBU zeigt leere MemoEdit Fenster bei Satz 3 und 4 (die ja noch Offsetverweise haben müssten ...)
9. Clipper 5.2e DBU hängt sobald man eines der Memofelder von Satz 3 oder 4 öffnen will.

obwohl gerade hier die Memofelder ja angefasst werden müssen. Aber es mag auch sein, dass "DbExport" (die Funktion, auf die COPY TO letztlich verweist) auch mit einem rudimentären Errorhandling oder etwas Ähnlichem ausgestattet ist.

Ich hatte sowas auch nur unter Clipper (Fehler beim Restore, nur DBF zurückgeschrieben), möglich dass die eine Sicherung eingebaut haben (wenn der Offset fehlt gib "" zurück ...).

[Werner_Bayern]

... womit wir wieder bei der Frage wäre "wo" bei dir "was" passiert das es zu dieser Situation gekommen ist. ( OS() / Netzwerk ... )

Servus Jimmy,

die 1 bezog sich auf die Anzahl der Felder. DBU zeigt korrekt 15 für die Länge des Textfeldes an und 10 für das Memo-Feld. Nur keine Sätze, wenn ich mittels F2 öffne. Durch das Umkopieren gings, ich denke, damit kann ich leben.
Erzeugt wurde die Datei mittels dbcreate aus meinem Programm heraus (wo die Sätze auch korrekt angezeigt werden!):

Code: Alles auswählen

dbcreate("textbl.dbf", {{"name", "C", 15, 0}, {"text", "M", 10, 0}})

Local auf der Festplatte meines Entwicklungsrechners.

[Werner_Bayern]

Ich finde die Quellcodes für CL-DBU nicht, aber es mag möglich sein, dass es eine implizite Fehlerbehandlung gibt.

Servus Tom,

das scheint es zu sein:

Code: Alles auswählen

* open the file and get handle
hhandle = FOPEN(M->hfile)

IF FERROR() = 0       * allocate 512 byte buffer
        htbuf = SPACE(512)

        * read the file header into memory
        FREAD(M->hhandle, @htbuf, 512)

        * isolate the correct 4 byte table entry
        htbuf = SUBSTR(M->htbuf, (4 * (M->hnum - 1)) + 1, 4)

DBU liest da direkt den Header ein und bedient sich offensichtlich nicht der entsprechenden Funktionen über die Anzahl der Sätze etc.

[brandelh]

Das finde ich aber sehr seltsam, dass die CL Leute nicht die internen Strukturinfos benutzt haben ...

[Alfred]

Hallo Thomas,

ich habe das Thema cdx nicht bemerkt, da ein Foxpro-Programmierer in der Regel
wegen der "rushmore technology" keine Indexe verwendet.

Ich habe dem Hersteller eine Mail wegen cdx gesendet, weil ich keine Funktionen
für Indexe in dem Viewer sehe.

Gruß
Alfred

[Tom]

Hallo, Hubert.

Das finde ich aber sehr seltsam, dass die CL Leute nicht die internen Strukturinfos benutzt haben ...

DBU war nicht nur als Tool konzipiert, sondern auch als Beispiel.