Lesefehler beim Anhängen von Datensätzen in dBase Datenbank

[TOmega]

Ich schiebe das Testprojekt mit einer leeren Tabelle in den Anhang. Ihr müsst die Tabelle aber erst mit ein paar tausend Datensätzen füllen, um den Fehler eventuell nachvollziehen zu können. Mit der leeren Tabelle kann ich auch jede Menge Datensätze ohne Probleme anhängen. Übrigens kan ich vorhandene Datensätze problemlos so viel und so oft verändern wie ich will. Auch Löschen von Datensätzen funktioniert (eigentlich logisch, da die Datensätze ja nur markiert und nicht entfernt werden). Schwierigkeiten macht nur die Vergrösserung der Tabelle oder anders gesagt die Veränderung der Anzahl der Datensätze.

Ich arbeite derzeit mit den BDE-Versionen 5.1.1 und 5.2. (Rechnerabängig)

In meiner Verzweiflung habe ich übrigens gerade mal auf einen Testrechner ein nacktes Windows installiert und dort probiert. Erfolg = 0;

[marabu]

Ich kann den Fehler bestätigen. Ich habe dein Testprojekt so erweitert, damit ich die Datensätze nicht alle von Hand eingeben muss. Im ersten Durchlauf wurden problemlos 5.000 Datensätze erzeugt (leer bis auf LFDNR). Im zweiten Durchlauf wurden noch 1.310 Datensätze angehängt, bevor der von dir beobachtetete Lesefehler auch bei mir auftrat.

Dass der Fehler nicht permanent auffällt mag daran liegen, dass, wenn überhaupt noch mit der BDE gearbeitet wird, überwiegend das Paradox-Format verwendet werden dürfte.

Soweit erstmal...

[webcss]

Schon mal dran gedacht, Native zuzugreifen, d.h. ohne BDE? Auf Torry gibt's einige freie Komponenten für DBase (allerdings ohne Multiindex (*.mdx) files)

[mkinzler]

Wenn er schon sein Projekt von der BDE weg entwickelt, sollte er gleich eine richtige Datenbank verwenden.

[Union]

Ich kann den Fehler nicht reproduzieren. Ich habe mit geändertem Code im FormShow zunächst 20.000 Sätze angelegt (Nach manueller Anlage eines "Beispielsatzes" zum Klonen). Dann wieder einen Satz manuell angelegt und gefüllt. Dann in 200er Schritten weiter. Alles funktioniert. Code für den ersten Durchgang:

Delphi-Quellcode:

procedure TForm1.FormShow(Sender: TObject);
const
  MaxRecCount : integer = 20000;
var
  aRecord : array of variant;
  i,j : integer;
begin
 Table1.Open;
 if Table1.RecordCount < 10 then
 begin
    Table1.First;
    SetLength(aRecord, Table1.FieldCount);
    For j := 0 to Table1.FieldCount-1 do
    begin
      aRecord[j] := Table1.Fields[j].Value;
    end;

    for i  := 0 to MaxRecCount - 1 do
    begin
      Table1.Insert;
      For j := 0 to Table1.FieldCount-1 do
      begin
        Table1.Fields[j].Value := aRecord[j];
      end;
      Table1.Post;
    end;

 end;

[TOmega]

@marabu:

Es ist schon mal gut, das jemand das Problem nachvollziehen kann. Wenn Deine Vermutung richtig ist, gibt es doch einen Bug in der BDE und die Umstellung auf Paradox sollte das Problem lösen (schön wär's).

@webcss:

1990 lief das Ganze noch unter DOS mit PowerBasic ohne Index. Mittlerweile ist der Index aber Dreh- und Angelpunkt in meinem Projekt. Ich denke die Umstellung auf Paradoxtabelle wäre einfacher.

@mkinzler:

Was meinst Du mit "richtiger Datenbank" ?

@Union:

Auf den ersten Blick sehe ich nur den Unterschied, dass Du mit Insert arbeitest und nicht wie ich mit Append oder AppendRecord. Ich weiss nicht welche Methode bei manueller Eingabe in DBGrid angewendet wird, aber ich vermute mal auch Append.

[marabu]

Inzwischen habe ich das Problem etwas untersucht und weitere Erkenntnisse: Der Lesefehler betrifft nicht die Tabelle, sonder den structural index file (MDX). Da ich alle Datensätze bis auf LFDNR leer lasse, entarten die vierzehn Feld-Indizes recht schnell. Eventuell gibt es da ein Limit. Wenn ohne Indexdatei gearbeitet wird, dann gibt es auch keine Probleme.

Freundliche Grüße

[mkinzler]

Bei einer richtigen Datenbank wird werden die Daten von einem Datenbankserver verwaltet. Cleinet fragt nur benötigte Daten an und nur diese werden an ihn übertragen. Bei filebasierten Datenbanken (wie z.B. dBase, Paradox, Access, ...) findet die Filterung am Client statt.

[Union]

Es könnte auch ein sog. Magic Number Problem sein. Das war jedenfalls früher mal ebei dBase eines. D.h. wenn ein Indexeintrag (und dann evtl. in Abhängigkeit vom alloziierten Speicher) eine definierte Grösse erreicht (z.B. 16384 o.ä) gibt es aufgrund eines Treiberbugs einen Overflow, der zum Absturz führt. Das kann man, wenn einem die kritische Größe nicht bekannt ist, durch Ausprobieren herausfinden: Schrittweises Vergrößern, oder wenn möglich, Verkleinern der indexierten Felder, damit nie eine solche Blockgröße auftreten kann.

[TOmega]

@mkinzler:

Mit dem Einrichten eines Datenbankservers würde ich wirklich Neuland betreten.
Es hört sich aber auch so an, als ob die Installation meiner Anwendung komplizierter werden würde, wenn ich das Programm weitergeben möchte.
Im Augenblick kann ich meine Anwendung ohne Installation von einem USB-Stick an jedem Rechner ausführen, selbst wenn die BDE nicht installiert ist. Ich muss nur die BDE-DLL's im Arbeitsverzeichnis haben.