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

[TOmega]

Seit einiger Zeit kämpfe ich mit einem Problem, und hoffe hier vielleicht einen Tipp zu bekommen.
In meinem Delphi-Programm nutze ich eine Dbase-Datenbankdatei. Dazu habe ich eine Datasource angelegt, mit einer Table verbunden und nutze ein DBGrid zur Anzeige, also nichts Kompliziertes. Datensätze können automatisch oder manuell hinzugefügt werden.
Anfangs lief alles wie gewünscht. Die Probleme begannen mit steigender Datensatzanzahl (inzwischen über 27000). Nach dem Anhängen von ca. 10-12 Datensätzen bricht das Programm mit einem Lesefehler der *.dbf Datei ab. Es hilft nur noch ein Neustart der Anwendung. Der zuletzt angehägte Datensatz ist dann nur unvollständig ausgefüllt. Nach einigen dieser "Abstürze" ist dann auch die Index-Datei hinüber und hat sich mächtig "aufgebläht". Ein Zeitproblem beim Speichern schliesse ich aus, da der Fehler auch bei manueller Eingabe auftritt.
Kennt jemand dieses Problem ? Gibt es vielleicht einen Bug in der BDE ?

[marabu]

Herzlich willkommen in der Delphi-PRAXiS, TOmega.

Wie sorgst du für das sichere Speichern deiner Daten?

Freundliche Grüße vom marabu

[TOmega]

Hallo marabu, danke für die schnelle Antwort.

Ich bin natürlich davon ausgegangen, dass das Speichern des Caches automatisch erfolgt.
Wenn ich Dich richtig verstehe, soll ich durch regelmässiges Aufrufen der Methode FlushBuffers für das Eintragen der zwischengespeicherten Daten sorgen. Ich habe das versucht, leider ohne Erfolg.

Wenn ich sage, dass das Problem nach ca. 10 Datensätzen auftritt, heisst das auch, ich muss das nicht am Stück tun. Wenn ich heute 9 Datensätze anhänge geht alles glatt und morgen bekomme ich dann schon nach dem ersten Datensatz das Problem.

[HaJo]

Hallo TOmega,

wie sehen denn Deine BDE-Einstellungen aus?

Gruß
HaJo

[TOmega]

Hallo Hajo,
im Grunde sind es weitestgehend die Standardeinstellung der BDE:

LOCAL SHARE = false
MINBUFSIZE = 128
MAXBUFSIZE = 2048
LANGDRIVER = dBase DEU cp437
MAXFILEHANDLES = 48
LOW MEMORY USAGE LIMIT = 32
DEFAULT DRIVER = DBASE
SHAREDMEMSIZE = 2048

Ich hoffe, das sind die Werte, die Dich interessieren.
Gruß TOmega

[marabu]

Hallo,

wenn sich dein Programm und die BDE-Konfiguration nach den ersten 25.000 Datensätzen nicht geändert haben und bis dahin alles problemlos lief, glaube ich nicht an eine fehlerhafte Einstellung. Du arbeitest nach einem Lesefehler doch hoffentlich nicht einfach weiter? Womit hast du die defekte DBF-Datei analysiert und repariert? Welche Version der BDE setzt du ein?

Freundliche Grüße

[Bernhard Geyer]

Hast Du einen Virenscanner der auch deinen dBase-Analysiert?
Falls ja, nimm diese Dateiextension aus dem Check heraus.

[TOmega]

@Bernhard Geyer:

Mein Virenscanner analysiert keine *dbf oder *mdx-Dateien. Testweise habe ich den Virenscanner auch mal komplett deaktiviert.

@marabu:

Ich habe mal mit einem Hex-Editor den Header und die letzten Datensätze der dBase-Datei untersucht und keinen Fehler in der Datenstruktur festgestellt. Nur der letzte Datensatz ist nicht vollständig ausgefüllt, was ich aber nach dem Neustart meiner Anwendung nachholen kann.
Ausserdem habe ich schon mehrfach mit dBase die Datenbank gepackt, also gelöschte Datensätze entfernt, und sortiert, wobei dBase ja eine komplett neue Datei erzeugt.
Es leidet also immer nur die Index-Datei und die habe ich auch schon mehrfach mit der Borland Datenbankoberfläche neu erzeugt. Mittlerweile habe ich eine Indexreparatur mit:

Delphi-Quellcode:

 DBIRegenIndexes(Table1.Handle);

in mein Programm aufgenommen.

Ursprünglich angefangen habe ich das Projekt vor Jahren mal unter Delphi 2. Es hat also schon verschiedene Versionen von Delphi, BDE und Betriebssystemen erlebt. Das Problem schein absolut Versionsunabhängig zu sein und tritt auch auf all meinen Rechnern auf.

Übrigens nutzt ein Bekannter von mir mein Programm auch. Er hat aber erst etwa 4000 Datensätze und keine Schwierigkeiten z.B. 200 Datensätze maschinell anfügen zu lassen (noch nicht). Darum glaube ich nicht an einen Programmfehler. Ich bin gespannt, wann bei meinem Bekannten die ersten Probleme auftauchen.

[TOmega]

Um sicher zu gehen, dass sich bei meinem Projekt in dem Codegewusel nicht doch irgendwo ein Fehler eingeschlichen hat, habe ich ein simples Testprojekt erstellt, also nur Datasource, Table und DBGrid. Der einzige Programmcode besteht also aus Table.Open; beim Start und beim Beenden Table.Close; Was kann man da noch falsch machen?
Ich habe also das Testprojekt gestartet und manuell im DBGrid Datensätze zugefügt und nach dem 11. oder 12. Datensatz wird wieder mit der Fehlermeldung "Lesefehler Datei: ....*.dbf" abgebrochen. Will man weiterarbeiten kommt der Fehler "Datenstruktur fehlerhaft". Erst nach Neustart der Anwendung kann man weitermachen (für die nächsten 12 Datensätze).
Hatte denn wirklich noch niemand ein ähnliches Problem oder ein Idee ?

[marabu]

Hallo,

stelle bitte mal dein Testprojekt zur Verfügung. Wenn die Test-Tabelle nicht im Programm erzeugt wird, dann packe sie als Leertabelle dazu. Welche Version der BDE hast du im Einsatz?

Freundliche Grüße

[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.

[mkinzler]

Bei Verwendung einer embedded-Datenbank muß auch nichts installiert werden. Zudem in die Weitergabe der BDE ohne Installation u.U. auch nicht ideal.

[webcss]

Zitat:

@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.

Die sind schon indiziert, allerdings eben nicht mit multiindex ala mdx, sondern mit singular index ala ndx...

Zitat:

@mkinzler:

Was meinst Du mit "richtiger Datenbank" ?

mkinzler meint sowas wie firebird, mysql, postgre, sqlserver...
firebird geht auch embedded und lässt sich einfach und gut skalieren.
sqlite ist gut für einfache programme wo es nicht auf concurrency, d.h. gleichzeitigen zugriff von mehreren clients, ankommt, ist klein und gut, wenn du in sql arbeiten willst.

[hsg]

Bevor du dich mit der BDE und/oder SQL rumschlagen musst, würde ich dir empfehlen dich mal mit dem ALS (Advantage Local Server) auseinander zu setzen: Der beherrscht .dbf Dateien, nur die Indizes müssten dann neu gemacht werden (Foxpro-Format wäre da zu empfehlen (.cdx)) und in deiner Applikation würden die TTable durch TADSTable ersetzt werden müssen. Vorteile: der Umstellungsaufwand ist gering (Einmal durch die DFM gehuscht und aus TTable ein TADSTable gemacht, das war's) und du bist die BDE entgültig los. Der Local-Server kostet nichts und es reicht die DLL mitzuliefern. Ein Installieren ist nicht erforderlich. Falls du später dann doch mal einen Datenbank-Server benutzen willst/musst musst du dann auch nichts umstellen.

Mehr findest du unter http://www.advantagedatabase.com

[hoika]

Hallo,

so viel zum Thema BDE.
Ich hatte (unter Paradox) auch mal das Problem mit zerschossenen Indizes.
Das war allerdings bei einem Kunden und nicht bei mir ;(
Das automatische Erzeugen auf 3 Rechnern
gleichzeitig lies den Fehler nicht reproduzieren.

Es spielt übrigens auch noch das Dateisystem eine Rolle
(unter FAT/FAT32 treten Fehler nicht so häufig auf)
und natürlich die Tatsache, ob die DB im Netz steht (Mehrfachzugriff).

"Einfache" Lösung: weg von DBase und Paradox.
Ich benutze hier die BDE immer noch (jaja),
allerdings unter Firebird,
bin aber auf dem Weg weg davon.


Heiko

[TOmega]

@mkinzler:

Natürlich habe ich für die Weitergabe meines Programms die BDE-Installation in das Setup integriert. Die Variante USB-Stick ist nur für mich gedacht, wenn ich schnell mal was nachsehen möchte und gerade keinen eigenen Rechner in Reichweite habe.

@webcss:

Ich habe da wirklich komplett ohne Index gearbeitet. Eingabe unter dBase IV und Abfrage mit einem Basic Programm nur aus der *.dbf Datei. Das lag auch daran, dass ich einfach nicht wusste, wie ich auf den Index zugreifen sollte. Das Format einer *.dbf Datei ist ja einfach zu verstehen.

@alle:
Ich danke Euch für die zahlreichen Vorschläge. Auf lange Sicht werde ich mich wohl von der BDE verabschieden. Dazu muss ich mich aber erst für eine Variante entscheiden und viel studieren und probieren. Da könnte mich demnächt der Faktor Zeit etwas ausbremsen.
Auf der Suche nach einer schnellen Lösung habe ich schon mal damit angefangen auf Paradox umzustellen. Die ersten Versuche sind positiv. Jedenfalls kann ich wieder ohne Probleme mehrere hundert Datensätze in einem Rutsch anhängen. Das liegt vielleicht nur daran, dass der Index jetzt auf viele Dateien verteilt ist und ich werde irgendwann wieder an die Grenzen stossen. Aber bei etwa zwei- bis dreitausend neuen Datensätzen im Jahr habe ich da wieder etwas Luft.
Wenn noch jemand eine zündende Idee hat, bin ich dankbar. Vorläufig werde ich die Frage aber als beantwortet markieren.

Gruss TOmega

[hoika]

Hallo,

ein Umsteig von Bde-DBase nach Bde-FireBird ist schnell erledigt.
man kann dann sogar mit den alten TTable arbeiten,
ab einer gewissen Record-Anzahl wird das dann allerdings langsam.

Ein Wechsel DBase->Paradox ist nicht ratsam.
Jetzt müssen statt einer Indexdatei mehrere Dateien
gepflegt werden und das geht mit schöner regelmässigkeit schief
(such mal nach "index out of date").

Das Problem ist ein veralteter Schreib / Lock - Mechanismus der mit
neuen Dateisystemen (NTFS, opportunistic lock)nicht mehr klarkommt.

Ich hatte damals ein grösseres Programm (600000 Zeilen)
in einer Woche umgestellt.
Naja, ab 50000 Datensätzen musste man dann
doch von TTable auf TQury wechseln.


Für Firebird (Interbase) gibt es auch Literatur dazu.

http://www.ibphoenix.com/main.nfs?a=...&page=ibp_skip
http://www.ibphoenix.com/main.nfs?a=...e=ibp_dbase_ib


Heiko

[hsg]

Zitat:

Zitat von TOmega

Auf der Suche nach einer schnellen Lösung habe ich schon mal damit angefangen auf Paradox umzustellen. Die ersten Versuche sind positiv. Jedenfalls kann ich wieder ohne Probleme mehrere hundert Datensätze in einem Rutsch anhängen. Das liegt vielleicht nur daran, dass der Index jetzt auf viele Dateien verteilt ist und ich werde irgendwann wieder an die Grenzen stossen.

Gruss TOmega

Mit dem Advantage Database Locale Server, hättest du dieses Problem nicht: FoxPro-Indizes sind ebenfalls Compound-Indizes, d.h. man kann mehrere Indizes in einer Datei haben.

[lofu1605]

setze mal LOCAL SHARE = true. Wenn die Datenbank lokal liegt habe ich häufig ähnliche Probleme bemerkt, die sich häufig auch nicht reproduzieren lassen. Wenn die Datenbank auf einem Netzwerklaufwerk liegt oder LOCAL SHARE = true steht tritt das Problem bei mir nicht mehr auf.

[TOmega]

Hallo lofu1605,
also ich habe keine Probleme mit der Reproduzierbarkeit des Problems.
Ich habe aber mal Deinen Vorschlag ausprobiert. Leider bringt das in dem Fall nichts.
Also Finger weg von dBase-Tabellen mit grossen Idizes. Bei 14 indizierten Datenfeldern wirft die BDE bei einigen tausend Datensätzen das Handtuch. Offenbar wurde in die dBase-Unterstützung schon längere Zeit nichts mehr investiert.
Übrigens treten unter Paradox diese Probleme nicht auf, obwohl je Index 2 Dateien gepflegt werden müssen. Inzwischen habe ich -zig mal die mehr als 27000 Datensätze maschinell in eine Paradox-Tabelle übernommen bei gleichzeitiger Aktualisierung der Indizes und danach auch noch mehrere hundert Datensätze angehängt ohne ein Problem.
Die wirklich bessere Lösung ist aber, die BDE nicht mehr zu nutzen.