BU29707, BU29706 Diskettenfehler (I/O-Fehler), 0:29999
 

Guten Morgen !

Seit einiger Zeit kämpfe ich mit einer "großen" Tabelle (ca. 240T) die mir ständig beim Record den I/O Fehler macht. Nun habe ich Datenbank Index mit unserem Tool repariert und versucht in eine neue Tabelle zu Übertragen. Dabei bekomme ich folgenden Fehler nach 6960 Datensätzen:

DB30118: Spaltentyp Fehler beim Übertragen.

In der neuen Tabelle sind die Felder dann ab diesem Datensatz verschoben, sodaß der Inhalt (zb. aus dem Memo) plötzlich in einer anderen Spalte steht.

Kennt das jemand zufälligerweise ?

Hat jemand von euch zufälligerweise eine Tabelle deren INDEX (IF) Datei > 50MB ist und könnt ihr die Datei poblemlos reparieren ?!

So, nach einigem Debuggen mit Ludwig sind wir einen Schritt weiter. Derzeit ist es wohl ein Fehler im OA4 wenn ein Indexfile (IF) die Größe von 32,0 MB oder 33.568.768 Bytes erreicht.

LSEEK() nimmt LONG als Offset und dummerweise sind 32MB genau die max. Größe. OA4 macht einen LSEEK wenn es ein IF erzeugt (schreibt); somit ein DOS Limit.

Würde man hier auf den Index schreiben müssen, wäre ein Absturz von OA4 unvermeidbar und die DB beschädigt.

Ludwig hat sich nun den Fehler genauer angesehen und folgendes herausgefunden:

8 ist das Handle auf das IF File und beim Erreichen des Limits springt er auf ein ungültiges Handle 9415; dabei erzeugt er einen DOS Fehler 6 = Invalid Handle. Das Handle ist im BX Register und dieses wird durch irgendwas "zerstört". OA4 zerschiesst sich somit seinen eigenen Filehandle. Ob das Problem durch einen "Patch" zu beheben ist, wird er sich freundlicherweise ansehen...

...to be continued

...nach weiteren Test's haben wir nun die Netzwerkversion als Fehlerquelle isoliert.

Die Vermutung mit dem lseek war natürlich Blödsinn, hat ja einen long-Parameter und keinen int. Sonst könnte ja kein DOS-Programm mit Dateien >32MB umgehen.

Falls es wen interessiert:

Die Problembehebung wird sich vermutlich als sehr schwierig bis unmöglich gestalten. OpenAccess ist in UCSD Pascal geschrieben. Nähere infos dazu gibt es z.B. hier: http://pascal.hansotten.com/index.ph...=ucsd-p-system

Das ist quasi eine Art virtuelle Maschine, die Bytecode ausführt, um Systemunabhängig zu sein. Das bedeutet, dass in der OA4.SPI kein echter Assemblercode steckt sondern sogenannter Pcode, welcher von einer virtuellen Maschine interpretiert wird. Genauer gesagt handelt es sich um ein Diskimage, welches der Interpreter dann mountet und verwendet. Jetzt ist es mir zwar gelungen, das Diskimage zu zerlegen und Dateien daraus zu dumpen. Jedoch kann ich die library-Dateien nicht in ihre einzelnen Module zerlegen. Selbst wenn mir das gelingen sollte (erachte ich noch durchaus als machbar), so könnte ich dann eventuell die einzelnen Routinen in PCODE disassemblieren. Nachdem man dann aber nur den reinen Code für die Stackmaschine ohne jegliche Referenzen hat, und auch ein debuggen ja nicht möglich ist, da man mit einem normalen Debugger ja nur den Assembler-Code durchsteppen kann, wird eine Analyse des Problems nahezu unmöglich. Denn wenn man im Debugger breakt, landet man prinzipiell einfach nur in der Interpreterschleife für den PCODE.

Insofern haben wir bei dem Pause-Enter Problem noch Glück gehabt, denn das scheint ein Problem der UCSD-Pascal Runtime gewesen zu sein und diese muss logischerweise in Assemblercode vorliegen.

Schlechte Karten also...

Hat sonst noch wer das Problem mit der Netzwerkversion?

Guten Morgen

ich habe hier eine Datei mit einer Indexgröße von 43 MByte diese lässt sich ohne Fehlerangabe
sowohl verkleinern als auch reparieren.
Allerdings wird dies in einer DOSEMU Emulation auf einem Linux-Rechner
erledigt.

Bei mir sind sehr viele Indexfelder und weniger Datensätze (123 T)
Größe der DF = 16 MB der MF = 12000 Byte!

Vielleicht hängt es ja auch mit der MEMO-Datei zusammen?

Mit der Standalone oder der Netzwerkversion ?? Ludwig hat es mit der Netzwerkversion auf dem DOSEMU probiert und da passiert der Fehler ebenso; die normale Einzelplatz geht einwandfrei.

Müsste eine Netzwerkversion sein

"Müsste" :-) ????