Datenverlust bei Systemabsturz mit Paradox-DB

[buyden]

Hi,

ich hab folgendes Problem mit einer Anwendung, die auf ner Paradox-DB basiert:

Sobald der Rechner abschmiert sind alle Daten, die seit dem Öffnen der Anwendung in die Datenbank geschrieben wurden weg. Schließe ich die Anwendung aber korrekt, wird alles ordnungsgemäß gespeichert.
Woran liegt das??

[Neelix]

Hallo buyden,

das liegt darin begründet, daß die BDE die Änderungen zunächst nur im Hauptspeicher zwischenpuffert. Erst wenn Du das Programm beendest, werden diese Daten in die DB zrückgeschrieben (beim Schließen der Datenbank). Meine Empfehlung: Rufe hin und wieder mal die Methode FlushBuffers von TTabel/TQuery auf. Dann werden alle Änderungen sofort auf die Platte geschrieben.

[buyden]

Sowas in der Richtung hab ich mir schon gedacht, aber hatte keine Lösung dafür.

Dankeschön

[Jelly]

Zitat von buyden:

Sobald der Rechner abschmiert sind alle Daten, die seit dem Öffnen der Anwendung in die Datenbank geschrieben wurden weg.

Dann sei froh, daß nicht die ganze Indizierung durcheinander geraten ist, und du die Tabellen überhaupt nicht mehr öffnen kannst.

Paradox ist alles andere als eine sichere Datenbank, und sollte imho vermieden werden. Es gibt genug Alternativen zu Paradox.

[Neelix]

Ich kann Jelly nur zustimmen. Wenn du in der DP ein wenig suchst Paradox Alternative findest Du auch den einen oder anderen Thread in dem mögliche Alternativen vorgeschlagen werden.

[buyden]

Ich werd das bei meinen nächsten Anwendungen mit bedenken aber das jetzt noch zu ändern wäre ein bisschen aufwendig.

Trotzdem Danke.

[MrSpock]

Hallo buyden,

auch wenn es mittlerweile fast zum Ritual geworden ist, möchte ich noch die Information los werden, dass Paradox häufig um einiges negativer dargestellt wird, als es wirklich ist. Wir verwenden noch immer Programme, die ich mit Paradox geschrieben habe, die im Netz mit bis zu 5 Usern laufen und die bis heute ohne Probleme laufen. Ich musste bei allen Programmen, die wir geschrieben haben insgesamt erst 2 oder 3 Mal die Indexdateien reparieren und das war in allen Fällen wegen eines Windows Absturz (der übrigens nicht durch unser Programm versursacht wurde ).

[Jelly]

Zitat von MrSpock:

Ich musste bei allen Programmen, die wir geschrieben haben insgesamt erst 2 oder 3 Mal die Indexdateien reparieren und das war in allen Fällen wegen eines Windows Absturz

Und was bitte schön kann man dabei postiv sehen?

[MrSpock]

Hallo Jelly,

derjenige der ein anderes Desktop Datenbankmanagementsystem benutzt, dass in etwa 10 Jahren (noch unter D1 entwickelt) bei der Nutzung in etwa 15 verschiedenen Programmen weniger als 3 Fehler hatte (die ich übrigens alle in wenigen Minuten behoben habe!), der melde sich doch bitte einmal.

Sowohl unsere Kunden als auch wir sind mit der Leistung von Paradox sehr zufrieden und sind froh, damals die Entscheidung für Paradox und nicht für Access oder ein anderes DBMS getroffen zu haben. Inzwischen wird die BDE und Paradox nicht mehr weiterentwickelt, was auch bei uns dazu führt, dass wir Stück für Stück auf Interbase oder für lokale Tabellen auf MyBase umstellen. Ich kann aber eben aus eigener Erfahrung nicht ohne Widerspruch Aussagen stehen lassen, die Paradox als DBMS schlechter machen, als es ist.

[shmia]

Zitat von MrSpock:

Sowohl unsere Kunden als auch wir sind mit der Leistung von Paradox sehr zufrieden und sind froh, damals die Entscheidung für Paradox und nicht für Access oder ein anderes DBMS getroffen zu haben.

Da habe ich genau die gegenteilige Erfahrung gemacht.
Ein Kunde hat ein Programm zur Wareneingangserfassung mit BDE/Paradox bekommen und hat ca. alle 2 Monate die Datenbank zerschossen.
Grund: in den Tabellen wurden AutoInc Felder verwendet. Durch ein abruptes Beenden des Programm wurde z.B. ein Datensatz mit der ID 31980 noch gespeichert. Der interne Generator stand aber noch auf 31979.
Keine Chance in diese Tabelle noch einen neuen Datensatz einzufügen.
Jedesmal musste der Kunde die Datenbank-Dateien mir zuschicken und ich musste mit RStruct und der veralteten Datenbankoberfäche 7 die Tabelle wieder reparieren.
Seit der Umstellung auf ADO mit Jet Engine 4 ist Ruhe!!!

Zum Entwickeln einer Datenbank gibt es kaum eine bessere Oberfläche als Access.
Ich sage damit nicht, dass Access eine gute Datenbank ist, sondern nur dass Access als Oberfläche für die Jet-Engine unschlagbar ist.