![]() |
AW: SQLite Dump mit FireDAC
Zitat:
Falls es da wirklich zu "Bröselerscheinungen" kommen sollte, wäre es an der Zeit die Qualität der eingesetzten Hard und Software zu hinterfragen. Von den og bin ich es gewohnt, daß sie über kurz oder lang Ausfallerscheinungen zeigen/zeigten. "Richtige DBMS" sind da durchaus zuverlässiger, Es sei denn sie befinden sich auf einer lokalen Festplatte, mit einem Benutzer vor der Tastatur, der immer noch ein Anhänger des BigRedKnob ist. Gruß K-H |
AW: SQLite Dump mit FireDAC
Zitat:
Jede Filebasierte Datenbank hat jedoch das Problem, das Zugriffe nicht richtig serialisiert werden können. Welcher User macht schon Datensicherungen? Wenn ich also mit meiner Wechselfestplatte immer zwischen zu Hause und meinen Büro pendele, kann es mal zu einen Lesefehler kommen... Wenn dann dadurch die ganze Datenbank nicht mehr erreichbar ist - ist das schlecht... Es soll - wenn überhaupt nur der Datensatz defekt sein, der auch in dem Sektor gespeichert wurde... Bei einer Bin-Datei kann ich einfach durch seeken...
Delphi-Quellcode:
Oder ich schreibe an jeden Record Anfang ein Magic - welches ich in einer zerstörten Datei finden kann...
for i:=0 to Sizeof(Datei) div RecordSize do
begin try seek(I*RecordSize); read... writeNewDB; except RecordIgnorieren end; end; Ich wollte jetzt aber nicht das Dateiformat von SQLite nach programmieren... Mavarik 8-) Ich ziehe die Frage hiermit zurück... :stupid: |
AW: SQLite Dump mit FireDAC
Ist bei den kleineren Dingern DBMS nicht eh jede Daenbank oder gar Tabelle eine eigene Datei?
Da kannst du doch auch im Programm regelmäßig ein Backup machen, indem die die Datenbank oder die einzelnen Tabellen klonst. Und bei Problemen eine ältere Version zurück spiels. ![]() Modernere DBMS arbeiten mit Transaktionen, wo änderungen erstmal in ein transaktionslog kommen, dann wird dieses Log in die Hauptdatei übernommen und erst wenn fertig, dann wird das Log gelöscht. Wenn man als bei Schreibvorgängen was kaputt macht (RoterKnopf, SteckerZiehn usw.), dann gibt es immer mindestens einen konsitenten Zustand und das DBMS kann abgebrochen Schreibforgänge wiederholen (reparieren), bzw. maximal die allerletzte Transaktion könnte verschwinden, wenn sie noch nicht vollständig gespeichert wurde. (Fehler am Datenträger, bzw. Änderungen während das DBMS offline war, mal ausgeschlossen) |
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:03 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz