Korrupte Datenbank

Die Korruption der Datenbank ist mittlerweile ja nicht mehr der GAU, da der SDF-Viewer das einigermaßen schnell mit "repair" und "compact" wieder hinbügelt. Trotzdem nervt es natürlich, jedes mal die Karte aus dem Gerät zu pfriemeln und in den externen Leser zu stecken (da es im Gerät ewig dauert).

Jetzt ist mir aufgefallen, dass die DB überwiegend und fast immer einen Schlag hat, wenn ich mehrere Caches, selektiert nach der jeweiligen GPX/PQ löschen lasse (delete using active filter). Kann es sein, dass dabei die DB nicht richtig abgeschlossen wird?

Oder kann jemand das Programm so umstricken, dass nach einer Löschaktion gleich automatisch die Funktionen repair und compact mit ablaufen?

Hi,
Das ewige Problem der Datenbank kompaktierung...

Im grunde gibt es sowas nicht. Ein gelöschter Eintrag in einer Datenbank bleibt immer als ungenutzter Platz in der Datenbaktdatei. dieser Platz kann auch nicht wiederverwertet werden.

Um die Datenbank von Ihren Gelöschten Einträgen zu befreien gibt es nur eine Möglichkeit.
Jeden einzelnen Datensatz aus der Datenbank auslesen und die Gültigen in eine neue Datenbank schreiben. Danach wird die alte gelöscht und die neue eingebunden.

Diesen Vorgang wird üblicherweise als Kompaktieren bezeichnet.

Soetwas würde ich nicht unbedingt auf dem PDA ausführen wollen.

um es nochmal ganz klar zu machen: Löschen gibt es in einer Datenbank nicht!
es werden nur Datensätze unsichtbar kekennzeichnet um die übersichtlichkeit zu erhöhen.
Die Datenbank kann nur immer grösser (und damit langsamer) werden. kleiner wird sie NIE.

Das alles hat nichts mit CB im besonderen zu tun. Es ist bei Allen Datenbankanwendungen dieser Welt so.

Gruß, Lucifer

Ich kenne nun das MS-SQL-Compact nicht...
Aber bei Oracle ist es sehr wohl so, dass man die Datenbank anweisen kann, Platz für gelöschte Datensätze/Daten physisch wieder freizugeben und auch neu zubelegen.
Allerdings verwaltet Oracle seine Datenbankfiles sogar auf physischer Ebene selbst. Das bedeutet man hat dort Datenbankfiles, die intern von Oracle bis auf Blockebene selbst verwaltet wird.
Allerdings gibt selbst Access, nicht verwendeten Platz auch wieder frei nach einer Komprimierung. So ist dort nach einem Massenlöschen von Datensätzen einer 100MB-Datenbank, auch nach dem Löschen die DB ebenso groß wie vor dem Löschen. Erst nach der Komprimierung hat die DB dann wieder ein paar KB im Extremfall.

Dennoch: Ich wunder mich, was da immer passiert. Ich selbst hatte jetzt nach einem Jahr Cachebox-Nutzung noch nie eine defekte DB.

Ja natürlich können die Datenbank frontends ihre Datenbank komprimieren. Das läuft dann aber über kopieren in eine neue Instanz der Datenbank und in der Zeit ist die Datenbank gesperrt da sonst die Intergrität nicht gewahrt werden kann.

Ich denke so ein kompaktieren dürfte auf einem PDA so ungefähr gleich lang wie das importieren einer PQ in eine neue DB dauern. Daher frage ich mich ob es geschickt ist sowas automatisch ablaufen zu lassen.

Als Option unter Tools als "Datenbank neu erstellen" könnte es sinnvoll sein. dies liesse sich auch gut mit dem Wunsch nach benutzung von mehreren Datenbanken kombinieren.

Gruß, Lucifer

Oracle macht das sozusagen "on the Fly", die Datenbank bleibt für alle Anwender im Zugriff. Allerdings ist eine Oracle-DB ja auch bisschen was anderes als Access oder so

Wie auch immer, gerade bei Cachebox besteht ja kein Problem damit, dass die DB von mehreren Usern im Zugriff ist.
Ich habe zwar noch nie eine DB-Reparatur gebraucht, den Bedarf gibt es aber wohl schon, was man hier so liest. Und ich kann mir Vorstellen, dass es einfacher/besser wäre für viele User, sich die DB schnell auf den PC uzu kopieren, zu reparieren und anschließend wieder zurück zu kopieren.
Ich erstelle mir ja ab und zu mal eine neue DB, da braucht der Import der PQ (und Bilder) aber dann schon mal gerne 2 bis 3 Stunden!
Weiterer Nachteil eines Neuaufbaus der DB: Alle Filednotes, händisch angelegte Waypoints etc. sind weg. Wer also einige gelöste aber nicht besuchte Mysteries oder halbfertige Multis mit seinem Cachebox verwaltet, für den ist das sicher eine Option. Ich denke es geht hier auch weniger um die "Komprimierung" aus Platzgründen sondern wirklich um die "Reparatur", weil die DB Fehler im Aufbau meldet.

ich hänge sehr an meinen Notizen und selbst erstellten Wegpunkten. Toll wäre es, wenn diese Caches in einer eigenen "has Userdata and/or Found"-DB liegen könnten. Dann wäre das Löschen der HauptDB immer wieder möglich. Vielleicht könnte man da auch ein Spezielles Fund-GUI-Basteln... (wenn man wieder mal Telefon-Joker ist). Die Krönung wäre dann noch ein festes Verknubbeln (importieren in ein Tracks-Field in DB pro Cache) von erstellten Tracks, das wäre der Überknaller. Das ganz dann noch weitergesponnen mit Cachbox@pc, dort könnte man dann im Vollbildschirm ein Gesamtansicht des Fund-Caches incl. Track in Kartenansicht, allen Wegpunkten, notizen und so weiter realisieren. Ein bisschen Statistik-Krams für das Cache-Profil usw. usw.
*träum*

Toll wäre...
Vielleicht könnte...
Die Krönung wäre...

Zum Vergrößern anklicken....

Kein Problem, Cachebox ist OpenSource

*träum*

Zum Vergrößern anklicken....

Nicht träumen, sondern machen

Also C# Buch kaufen, ein paar Tutorials im Internet durcharbeiten und los geht es.

Mein erster Versuch war schon sogleich beendet, als ich feststellte, dass ich das frisch installierte Studio2010 nicht zum Kompilieren von Cachebox verwenden konnte. Anonsten sind meine c#-Versuche erst in den Anfängen. Mein größtes Problem ist die fehlende Zeit. Ich hätte so viel Lust mal wieder richtig zu Programmieren. Ist schon sehr lange und mehrere Programmiersprachen her...
Mit 'nem Studio2008 hab ich ein funktionierendes CacheBox-CAB erzeugen können. Mal sehen, wann ich da soweit durchsteige, dass ich auch brauchbaren Input liefern kann.

Ach ja... auch bei open source muss man sich abstimmen und vorher diskutieren, bevor einfach was gemacht und eingechecked wird. (ist meine Meinung) und einen Anfänger einfach so an das Datenbank-Design ranzulassen schon fast fahrlässig.