SiDiary > Symbian

Datenbank def. ??

(1/3) > >>

Attu:
Hallo Daniel,

benutze  Symbian  S60 V3 im Nokia E72

C-Diary 1.25.

Ich hatte bis gestern abend noch daten eingegeben.
Als ich nun gestern Nacht nochmals Daten eintragen wollte, offnete sich C-Diary mit dem Start-Bildschirm und nach bestätigung schloß es gleich wieder.

Da ich natürlich ständig Daten eingebe, habe ich die DB  "weggesichert" und eine neue Datenbank begonnen.

Mit der neuen Datenbank geht alles.
Wenn ich die "alte" wieder verwende, ist wieder selbes Verhalten wie oben beschrieben.
Vermutlich hat die DB einen "schuß".

nun die Frage, kannst Du die Daten wieder herstellen, bzw als Excel-export lesbar machen zum nachtragen.
der letzte Air-Sync hat am 21.6. statt gefunden.
Also fehlen die Tage vom 21.6. bis 27.6.

Gruß   Peter

daniel:
Hallo Peter,
wenn du nichts dagegen hast, dann schicke mir doch die defekte Datei, und ich sehe, was ich tun kann.
Klingt in der Tat so, als wäre die Datei defekt.
C-Diary legt Backup-Dateien an. Hast du eine davon (von vor dem Zeitpunkt, ab dem die Originaldatei nicht mehr funktionierte) ausprobiert? Die sollte dann eigentlich noch lesbar sein, und darin fehlt dann vermutlich nur der letzte Eintrag, bei dem das Malheur passiert ist. Wenn du die Backup-Dateien mit "weggesichert" hast, reicht ein Umbenennen der letzten Backup-Datei in den Originaldatei-Namen, und die Backupdatei kann als Datenbankdatei verwendet werden.

Gruß
Daniel

Attu:
Hallo Daniel,

ich schick dir mal die dateien, allerdings wir es heute etwas später.

ich hab  folgende Dateien:

c_diary.dat
c_diary.bak1
c_diary.bak2

Ich hab mal die c_diary.bak1 in c_diary.dat umbenannt,
aber da kam sofort eine fehlermeldung, daß die datei nicht lesbar wäre.

Oder sind die Backup dateien in einem spwziellen Verzeichniss ?????

Gruß Peter

daniel:
Hallo Peter,

sorry für die späte Antwort - gestern bin ich nicht mehr dazu gekommen zu antworten.

Die Dateien c_diary.bak1 und c_diary.bak2 sind schon die richtigen (liegen im selben Verzeichnis wie die Datei c_diary.dat).
Wenn die bak1 auch nicht lesbar ist, dann probiere es mal mit der bak2 (hast du die baks gleichzeitig mit der beschädigten dat-Datei "weggesichert", sind das also auch genau die bak-Dateien, die zu der dat-Datei gehören?)

Ich habe deine Mail erhalten. Werde mich heute drum kümmern und mich per Mail zurückmelden.

Gruß
Daniel

daniel:

Rückmeldung doch nicht per Mail, sondern hier öffentlich, denn das ist sicher auch für andere interessant (auch wenn hoffentlich noch niemand anders von so einem Problem betroffen ist!):


Hallo Peter,

ich habe mir deine Dateien angesehen: Es sind leider alle drei Dateien (dat, bak1 und bak2) defekt, alle mit leicht unterschiedlichen Defekten.

Der Grund ist folgender:

Ich habe in C-Diary einen Mechanismus implementiert, der beim Laden der Datenbankdatei automatisch auf die nächste intakte Backupkopie zurückfällt, wenn die Hauptdatei defekt ist (Reihenfolge: Versuche, .dat zu laden, wenn korrupt, versuche .bak1 zu laden, wenn korrupt, versuche .bak2 zu laden).
Aber dieser Mechanismus greift eben nur beim Laden, und du hast vermutlich C-Diary fast immer offen, trägst Daten ein und speicherst diese fleißig, aber in die Situation, die Datei zu laden, kommst du dann nur selten (z.B. nur nach Neustart des Telefons), und mein Rückfallmechanismus greift daher nicht.
So pflanzt sich ein Fehler in der Datenstruktur (evtl. verursacht durch ein Symbian-Bug, RAM-Defekt, kosmische Strahlung (kein Scherz)..., evtl. natürlich auch durch ein C-Diary-Bug, was ich aber für wenig wahrscheinlich halte, da bisher sonst niemand so einen Fehler gemeldet hat) über die Backupkopien fort. Das ist ein Fall, den ich beim Programmieren nicht beachtet habe.

Leider habe ich aber auch nicht die Möglichkeit, mit vertretbarem Aufwand die intakten Daten aus deiner Datei herauszuziehen.
Der Grund dafür ist, dass ich in dem Framework, in dem ich programmiere, die Datei dadurch erzeuge, dass ich die Datenstruktur so, wie sie im RAM liegt, direkt in die Datei kopiere (und umgekehrt). Das ist ein simples Kommando wie (vereinfacht):
"file.write(file, database)"
bzw.
"file.read(database, file)"
d.h. die Struktur, in der die Daten in der Datei abgelegt sind, ist mir gar nicht im Detail bekannt. In deinem Fall schlägt dieser monolithische read()-Befehl fehl, und es werden KEINE Daten in den RAM geladen, d.h. ich kann auch keine Daten auslesen.
Ich müßte sehr aufwändig versuchen, diese Datenstruktur empirisch zu ermitteln, um einen Datei-Parser zu programmieren, der bis zur fehlerhaften Stelle die Daten extrahieren kann.
Das würde ich zwar gern tun, aber dafür fehlt mir die Zeit. Tut mir wirklich leid!

Ich werde aber Folgendes tun:
Ich werde im Programmcode (fließt dann in die nächste Version, 1.26, ein) einen Mechanismus einbauen, der die Datei nach jedem Speichern neu lädt, so dass C-Diary sofort nach dem Speichern merkt, wenn die Datei korrupt ist, und dann auf eine intakte Backupkopie zurückfällt (d.h. die seit dem letzten manuellen bzw. automatischen Speichern eingegebenen Daten wären dann wieder verschwunden, es wird auch eine entsprechende Warnung ausgegeben).
So vermeide ich, dass sich ein Fehler in der Datenstruktur, der sich einmal eingeschlichen hat, bei kontinuierlicher Verwendung von C-Ciary (also ohne zwischenzeitliches Neuladen der Datei) über alle verfügbaren Datenbankkopien (dat, bak1 und bak2) fortpflanzt und so immer mindestens eine intakte Datei existiert.

Das verlängert die Zeit, die C-Diary zum Speichern braucht, etwas, aber ich denke dass das ein Preis ist, den man für diese zusätzliche Sicherheit gern zahlt.

Evtl. werde ich das Timeout für die automatische Speicherung dann von 15 Sekunden auf vlt. 30 Sekunden erhöhen, damit man nicht so oft vom längeren Speichern gestört wird, wenn man Daten in langsamer Folge eingibt oder bearbeitet.

Viele Grüße,
Daniel

Navigation

[0] Themen-Index

[#] Nächste Seite