Ich habe ein Programm geschrieben, was auf einer Paradox 7 Tabelle aufbaut. Die Zugriffe auf die Tabelle erfolgen über TTable.

Nun habe ich festgestellt, dass die BDE die Daten ewig (fast 10.000 Datensätze --> insg. über 1MB) im internen Cache liegen hat und die Daten erst sehr spät auf die Platte geschrieben werden. Damit sind bei einem Systemchrash oder Stromausfall alle Daten verloren, was natürlich nicht so schön ist.

Um dies zu umgehen rufe ich in der Ereignisbehandlungsroutine für OnAfterPost TTABLE.FlushBuffers aus. Das bringt Abhilfe, allerdings werden die Daten nicht bei jedem neuen Datensatz auf die Platte geschrieben. Den internen Schreibcache der Platte habe ich bereits abgeschaltet. Möglicherweise cached XP (SP2) die Daten noch irgendwo.?

Folgende Zeilen habe ich in einem anderem Forum gefunden:


Funktioniert aber ebenso nicht 100%-ig wie FlushBuffers.

Beim Schließen der Datei werden die Daten dann definitiv geschrieben. Ständiges Öffnen und Schließen kann ja aber nicht die Lösung sein.

Hat da evtl. jemand eine Lösung?

Prinzipiell bin ich bei dieser Anwendung nicht unbedingt auf die Paradox-Tabelle angewiesen und könnte jedes beliebige andere Format verwenden. Sieht es dort besser aus oder habe ich da die gleichen Probleme.

MfG
Steffen

Du solltest irgendeine Datenbank benutzen, die ohne BDE auskommt. afair cached die BDE auch nochmal die Daten. Da du aber nicht auf Paradox angewiesen bist, solltest du die BDE ganze rausschmeißen, da diese sowieso nicht mehr gewartet wird.

Moin
Mal abgesehen davon, dass ich mit jasocul vollkommen übereinstimme, würde mir spontan zu TTAble die Eigenschaft CachedUpdates einfallen: sollte nicht uaf True gesetzt werden, damit alle Änderungen sofort physikalisch eingetragen und nicht erst zwischengespeichert werden...

Danke schon einmal für eure schnellen Antworten.

@raiguen
Die Eigenschaft CachedUpdates ist auf false. Die Änderungen werden trotzdem in einem riesigem Cache abgelegt und geändert. Wie gesagt, es waren rund 10.000 Datensätze.

@jasocul
Was gibt es denn da an Möglichkeiten? Wichtig ist, es darf natürlich nichts kosten und muss Delphi5 noch unterstützen. Die Anwendung ist recht einfach, zur Not könnte ich das selbst auch mit einer Ascii-Tabelle lösen. Was Fertiges einzusetzen wäre natürlich wesentlich einfacher, da es doch recht große Datenmengen werden können.

MfG

In deinem Fall würde ich Firebird empfehlen. Das funktioniert auch als Embedded Version, d.h. ohne echten Server und erforder keine großartige Installation. Wenn ich mich richtig erinnere müssen nur zwei Dateien kopiert werden. Allerdings ist jede Doku, die ich finden konnte auf englisch. Suche einfach mal nach Firebird im Forum. Da wirst du sicher eine Menge Treffer und Hinweise finden.

Danke, ich schaue es mir mal an. Doku auf englisch ist kein Problem, hauptsache es gibt eine.

MfG
Steffen

Moin
Wenn ich auch mal eine Tipp loswerden dürfte
Schau Dir mal Absolute Database an! Ist auch für Delphi 5 geeignet und funzt tadellos. Zum Umsetzen der ParadoxTabellen gibt es sogar gleich ein entsprechendes Tool, ein DatabaseManager incl. SQL-Builder ist ebenfalls vorhanden. Dokumentation ist auf Englisch, aber leicht verständlich. Alles for free

Schaue ich mir natürlich auch mal genauer an.

So weit, wie ich beides jetzt überflogen habe bräuchte ich für Firebird noch entsprechende Zugriffskomponenten, welche bei AbsolutDatabase gleich (relativ kompatibel zu TTable und TQuerry) mitgeliefert werden. Was kostenloses für den kommerziellen Einsatz scheint es nicht zu geben. Zum austesten kann man ja aber erst einmal die freihen Varianten verwenden.

Vor allem die Konvertierungstools von AbsolutDatabase sehen recht gut aus. Ich habe auch eine größere Applikation am Laufen, die irgendwann mal auf den neuesten Stand gebracht werden muss. Basiert im Moment auch auf einer Paradox Datenbank. Je einfacher die Konvertierung von Code und Datenbank dann wird, um so besser.

MfG
Steffen

Für Firebird gibt es ZEOS (würde ich aber nicht nehmen) und die Komponenten für Interbase. Die sollten bei Delphi 5 auch dabei sein.
Übr Advanced Database habe ich noch nichts negatives gehört. Eine Version habe ich zuhause, kostenlos über die Delphi-Tage bekommen. Installiert ist die schon, konnte aber noch nicht richtig testen (keine Zeit). Der Support ist aber ziemlich gut und schnell (Hatte Schwierigkeiten bei der Installation, weil ich die falsche Version installiert hatte).
Soweit ich sehen konnte, wird bei Adv.DB für jede Tabelle und Index eine Datei angelegt. Vom Prinzip also so ähnlich wie bei Paradox. Bei Firebird gibts "nur" eine Datei pro Datenbank. Da ich Oracle gewohnt bin, würde ich natürlich Firebird den Vorzug geben.
Aber das ist natürlich Geschmackssache.

jasocul hat folgendes geschrieben:

Soweit ich sehen konnte, wird bei Adv.DB für jede Tabelle und Index eine Datei angelegt. Vom Prinzip also so ähnlich wie bei Paradox. Bei Firebird gibts "nur" eine Datei pro Datenbank...

Im Prinzip richtig, allerdings werden alle diese Dateien in eine 'große' Datei gekapselt mit der Default-Endung *.ABS. Ich denke mal, dass bei FireBird bzw Oracle es ähnlich gemacht wird?
Ich denke mal, wenn man relativ schnell von BDE umsteigen möchte, ist AbsDB durchaus empfehlenswert, weil gut dokumentiert...
DBISAM wäre auch noch eine interessante Alternative (leider ebenso kostenpflichtig für kommerziellen Einsatz wie AbsDB); auch hier ausgezeichnete Dokumentation und ausführliche Referenz etc...
Aber wie gesagt, alles reine Geschmackssache

Wobei ich die 99,-$ für die Singel-User Lizens für den kommerziellen Einsatz nicht als ein Hinderniss sehe. Wenn die Doku wirklich sehr gut ist, spart man sich dann schnell mal ein paar Stunden Arbeitszeit und das Geld ist wieder drin.

Wie sieht es eigentlich bei den beiden Alternativen mit dem Import der Daten z.B. in Excel oder andere Tabellenkalkulationssoftware aus? Ein Teil unserer Kunden will die Daten dann (aus Kostengründen) selbst weiterverarbeiten. Für Paradox z.B. gibt es entsprechende Tools.
Gut, wäre auch kein Thema dafür eine ASCII-Datei zu erstellen.

MfG
Steffen

Moin
@Steffen:
um noch mal auf Deine Eingangsfrage zurückzukommen: Wie sieht die BDE-Einstellung bei LOCAL SHARE aus? Setz die mal auf TRUE, dann sollten die Zwischenspeicherungen von TAbellenänderungen nicht mehr vorkommen...
BDE-VErwaltung -> Konfiguration -> System -> Init

Hallo Rainer,

Local Share ist auf True gesetzt. Trotzdem werden die Datensätze nicht sofort physikalisch geschrieben. Der Festplattencache ist ebenfalls abgeschaltet.

Einzig beim Schließen der Table werden die Daten vollständig auf die Platte geschrieben. Da werde ich wohl oder übel doch auf ein anderes Datenbanksystem umsteigen müssen.

MfG
Steffen

Hallo Steffen,
soviel also zur BDE*grins* Hätte mich auch gewundert, wenn das gefunzt hätte (hab' den Tipp irgendwo im weltweiten Datenmüll gefunden )...
EIn Umstieg auf ein BDE-freies Datenbanksystem bringt auf jeden Fall was; die Zeit bzw der Aufwand des Umstellens lohnt sich...
Auch ich habe diesen Schritt vollzogen und ein umfangreiches Projekt BDE-frei gemacht; meine Kunden brauchen sich nun nicht mehr mit zerschossenen Index-Dateien oder korrupten Headern, verschwundenen Daten etc rumärgern (passiert immer gern dann, wenn die BDE im Netz arbeitet und einige zig Benutzer gleichzeitig am werkeln sind...)