Access mdb-Datei sichern und wiederherstellen

Velow

Mitglied
Hallo leute, ich komm einfach nicht weiter.

Ich habe eine mdb Datenbank in meinem Hauptverzeichnis die ich für Berechnungen nutzte.

Soll heißen: vor dem Start ist die Datenbank leer (nur das Schema vorhanden). Bevor das Java-Programm geschlossen wird, werden alle Daten wieder gelöscht.

Das Problem dieser tollen Access-Datenbank ist leider, dass gelöschte Daten nicht entgültig gelöscht werden. Das heißt also, dass die Datenbank mit der Zeit immer größer wird.

Und jetzt zu meiner Idee. Nach dem Programmstart möchte ich die Datei einlesen und bevor das Programm geschlossen wird, soll es wieder zurückgeschrieben werden.

Hier meine 2 Funktionen:


Sichern/einlesen:
Code:
public static String readFileAsString(String filePath) throws java.io.IOException{
            byte[] buffer = new byte[(int) new File(filePath).length()];
            FileInputStream f = new FileInputStream(filePath);
            f.read(buffer);
            return new String(buffer);
        }



Zurückschreiben:
Code:
try {
   File ausgabedatei = new File("Daten.mdb"); 
   FileWriter fw = new FileWriter(ausgabedatei); 
   BufferedWriter  bw = new BufferedWriter(fw); 
   bw.write(Start.Start.DBbackup);
   bw.close();
} catch (IOException e) {
   e.printStackTrace();
}

Mein Problem ist jetzt, dass die Datei nach dem zurückschreiben beschädigt ist. Warum ? :(
 
Zuletzt bearbeitet:
... Beschädigt ist deine Datei vermutlich, weil du nicht einen binären OutputStream, sondern einen Writer verwendest. Das Einlesen mittels eines InputStreams ist ja schon richtig, das Schreiben musst du aber anstatt mit einem Writer mit einem OutputStream bewerkstelligen. Außerdem gefällt mir nicht, dass du den InputStream nicht sauber schließt.

Außerdem denke ich, dass es besser wäre, wenn du nicht vor dem Programmstart die mdb-Datei einlesen würdest und zum Schluss "wiederherstellen", sondern die mdb-Datei als Ressourcen-Datei in die Jar des Programms einbindest und sie dann beim Programmstart einfach von deinem Programm extrahieren lässt. Beim Programmende könntest du die benutzte Datei dann einfach löschen und die Sache wäre damit gegessen. Der Grund, warum mir deine Methode nich wirklich zusagt ist ganz einfach: Du liest die mdb-Datei ein und benutzt die eingelesenen Bytes erst beim Programmende. Bis dahin sind diese Bytes also nutzloses Beiwerk, die unnötig im RAM liegen. Ich meine das werden nur ein paar Kilobytes sein, für die heutige Zeit nix gravierendes, aber unschön ist es dennoch ;) Was ich aber nicht verstehe ist, warum die Datei bei dir scheinbar wächst, wenn du doch alle Daten löschst o.O
 
Zuletzt bearbeitet:
Danke für deine schnelle Antwort ! Das mit dem binären OutputStream werd ich gleich mal versuchen. Und hier nochmal die Info warum eine Access-Datenbank "wächst". Hab ich aus einem anderen Forum.

Bei jeder Änderung, Neueingabe oder Löschung in einer RDB wird ein benutzter Speicherbereich als "ungültig" markiert und der komplette Datenbestand irgendwo anders hingeschrieben. Ist der von Dir geänderte Datenbestand sehr groß, nimmt entsprechend auch der Speicherplatzbedarf der DB zu. Sprich, da ein RDBMS ungültige Speicherbelegungen nicht sofort freigibt, ist das Aufblähen der DB mit der Zeit unvermeidbar (abhängig von der Größe der Dateneinheiten und der Änderungsfrequenz).

Damit nicht jede DB irgendwann die Größe einer Galaxie annimmt, muss man in bestimmten Zeitabständen reorganisieren. Bei Access heißt das "Komprimieren" und findet sich unter "Extras"/"Datenbank-Dienstprogramme". Aber das wusstest Du sicher schon.
 
Ok, wieder was dazugelernt ^^

Zu den Streams: Es gibt textuell arbeitende Streams (Reader und Writer) und binäre Streams (InputStreams und OutputStreams). Reader und Writer werden eben für textbasierte Anwendung verwendet, z.B. Textdateien, Interaktion des Benutzers (z.B. Kommandozeile), also einfach Bereiche, wo man wirklich mit Text konfrontiert wird. Binäre Streams dagegen gehen tiefer auf die binäre Ebene. Damit lassen sich dann alle Dateien verarbeiten. mdb-Dateien z.B. sind keine Textdateien, also binär verarbeiten.
 
Zuletzt bearbeitet:
Zurück