Nachdem die DB doch schon eine ordentliche Größe hat wollte ich sie komprimieren und hab die im Anhang vorliegenden Meldungen bekommen.
Die Funktion ist allerdings gewährleistet, d.h. keine Probleme festgestellt.
Was ist zu tun?
Datenbankkomprimierung - Fehlermeldung
-
Hallo gm,
zunächst würde ich erstmal ein Quickbackup machen, einfach nur um einmal alle Daten zu sichern.Danach einen Rechnerneustart um sicher zu sein das es nirgendwo klemmt.
Dann noch mal einen Versuch starten mit dem Komprimieren.
Wenn wieder eine Fehlermeldung kommt, hat die Datenbank offenbar irgendwo einen Knacks.
Da Du ja offenbar noch auf alle Daten zugreifen kannst, würde ich in diesem Fall einfach eine neue Datenbank erstellen, z.B. Datenbankname2 und die Tabellen über Kopieren und Einfügen in die neue Datenbank übertragen.Dann wurde ich bei geschlossenem QV im Windows Explorer die Datenbank umbenennen, z.B. die Dateiendung qu5 durch bak ersetzen, QV neu starten und das Komprimieren erneut starten. Die Fehler sollten jetzt weg sein.
Gruß
Denis -
Hallo Denis,
ich hatte natürlich ein Backup vorher angelegt.
Auch das mit dem Neustart.Die einzelnen Dateien hab ich jetzt wie du beschrieben hast in eine neue DB verschoben, die Alte umbenannt.
Hat soweit funktioniert, dann neu komprimiert.
Dieser Fehler ist weg, lediglich ein anderer Hinweis - schau mir den noch mal an.Danke vorerst!
-
Hallo, ich hänge mich hier mal an...
Bei mir (7.1.0.21 PU) tritt der selbe Fehler bei 17 von 39 Datenbanken auf, eigenartigerweise beginnend bei einer bestimmten und ab dieser ohne Ausnahme bei allen weiteren Datenbanken (DB 23-39).
Bei der ersten der betroffenen DB hatte ich zuvor einen Fehler bei den Tracks (...error, konnten nicht angezeigt werden) und alle WP aus dem WP-Verzeichnis dieser DB waren verschwunden.
Waren alle aus QV4 importierte Datenbanken.
Habe nun mal eine neue DB erstellt, aus einer der fehlerbehafteten alle Daten in diese kopiert und die beiden DB dann im Explorer umbenannt. Danach ließ sich die neue DB komprimieren und die alte wurde gelöscht..Muss ich jetzt bei weiteren 16 DB machen.
Doof ist halt, weil ich keine Ahnung habe, warum das so ist und öfters möchte ich dieses Prozedere auch nicht machen müssen.Gruß,
Robert[Edit]
Nachdem ich die erste der betroffenen DB neu erstellt hatte (die mit den defekten Tracks), lief das Komprimieren wieder vollständig fehlerfrei durch alle DB.
Der Fehler lag also in dieser einen DB und die Folgenden gaben als "Folgeerscheinung" auch Fehler aus, waren aber doch in Ordnung.Gruß,
Robert -
Guten Morgen!
Von der defekten Datenbank gibts natürlich auch keine funktionierende Sicherung, die wurde nämlich schon mehrmals defekt überschrieben...
Habe aber glücklicherweise noch eine alte *.grm mit den WP der defekten DB gefunden, die sich aber leider mit QV7 nicht mehr öffnen bzw importieren lässt (oder ich bin im Moment zu blöd dafür). Nach einigen weiteren grauen Haaren das gute alte TTQV4 installiert, die *.grm problemlos importiert und als *.gpx wieder exportiert (*.wpt ließ sich nämlich in QV7 auch nicht importieren?).
Aus dieser *.gpx konnte ich meine WP im QV7 dann endlich wieder herstellen.Der Verlust dieser Daten hätte mich wirklich sehr geärgert, das waren vor zehn Jahren 2 wunderschöne Marokko-Touren.
Bleibt nur noch die Frage: kann QV7 mit den alten Formaten wie *.grm, *.wpt etc. nicht mehr umgehen?Gruß,
Robert -
-
Aber ich muss noch mit dem erhobenen Zeigefinger die Frage stellen, warum so viele Nutzer hier keinen Gedanken daran verschwenden, ab und zu mal ihre Daten zu sichern. Macht Ihr das bei anderen Daten auch so?
In QV geht die Sicherung dermaßen einfach, dass ich mich schon wundern muss. Einfach beim Programmende die Funktion "Quick Backup - Ende" wählen.
-
Aber ich muss noch mit dem erhobenen Zeigefinger die Frage stellen, warum...
Servus!
Naja, ich schrieb ja, dass ich gesichert hatte.
Wenn das Backup aber kommentarlos erstellt und der Fehler mit gesichert wird, stehe ich letztendlich mit einer zwar einfach gesicherten, aber trotzdem defekten Datenbank im Regen. So schauts aus.
Meine Frage, ohne erhobenen Finger: was soll ich dagegen tun?
Ich wundere mich gerade ebenfalls.Nebenbei:
bei mir läuft QV7
die DB liegen im Verzeichnis QV5
das Quickbackup erstellt eine Date namens QV6 ...?Gruß,
Robert -
Habe aber glücklicherweise noch eine alte *.grm mit den WP der defekten DB gefunden, die sich aber leider mit QV7 nicht mehr öffnen bzw importieren lässt
sollte gehen. Was für ein Fehler? Kannst Du uns die mal zukommen lassen zum checken?
Tom -
Wenn das Backup aber kommentarlos erstellt und der Fehler mit gesichert wird
Das Quickbackup macht keine Komprimierung, daher werden Fehler mit gesichert, das ist richtig.
Aber es überschreibt niemals ein älteres Backup, so daß theoretisch irgendwo ein alter Stand vor dem Fehler hätte vorhanden sein können.
Tom -
Hallo,
wenn das Backup läuft und defekte Daten sichert, dann nutzt das Backup natürlich nichts.
Eine defekte Datenbank kommt vor, aber wenn ich das hier verfolge, dann kommt das nicht häufig vor - wenn, dann triftt es allerdings hart, weil u.U. die Daten unwiederbringlich verloren sind.Als Vorschlag eine Strategie, das Risiko zu minimieren. Bei einer Datenbank ändern sich nicht ständig die Inhalte und daher kann man auch Zwischenstände an einem anderen Ort sichern. Am besten liegt das nicht auf dem gleichen Rechner, wenn es keine Daten sind, die man unbedingt nur im eigenen Netzwerk belassen möchte, lokal auf einer anderen Platte und in einer cloud sichern. Bei der cloud kann man das noch verschlüsseln, sollte sich aber dann sicher sein, dass man die langfristig auch wieder entschlüsseln kann.
Zusätzlich kann man die Daten auch noch in ein anderes Format wie GPX exportieren und das komprimieren, weil dann hat man, wenn eine Datenbank verlorengeht, zumindest noch die GPX Daten. Auf die alten Garmin Formate würde ich nicht mehr setzen, aber wenn die noch vorhanden sind und lesbar sind, muss man sie nicht wegwerfen, kann sie aber ggf. auf GPX konvertieren.Dann hat man die Datenbanken getrennt - Sicherungspunkte, für ein längerfristiges Backup und Arbeitsdatenbanken. Die Arbeitsdatenbanken sichert man wie bisher mit dem Backup und bei größeren Änderungen macht man die oben beschriebene Strategie und kopiert den neuen Zwischenstand (ohne den vorheringen Zwischenstand zu überschreiben!) wieder in sein anderes Backup (kann man ja z.B. das Datum anhängen oder nutzt eine Backupsoftware, die mehrere Zwischenstände aufhebt und nicht nur den letzten Stand). Das ist auf den ersten Blick etwas mehr Arbeit, aber wenn eine Datenbank defekt ist, hat man ein weiches Polster, auf das man zurückfallen kann.
Ein paar Datenbanken werden sich nicht ständig ändern und wenn Vor- und Nachbereitung abgeschlossen sind, werden sie länger unverändert bleiben, so dass der Zusatzaufwand sich in Grenzen hält. Das muss nicht ein Fehler von QV sein, wenn eine Datenbank kaputt geht - die Daten altern auf der Festplatte oder wenn diese defekte sektoren ansammelt, kann so etwas auch passieren. Einfach die vorhandenen Daten in ein anderes Verzeichnis kopieren mag einfacher und schneller sein, aber damit schließt man solche Fehler nicht aus. Daher kann sich der Mehraufwand für solche Daten lohnen.
-
Wenn das Backup aber kommentarlos erstellt und der Fehler mit gesichert wird, stehe ich letztendlich mit einer zwar einfach gesicherten, aber trotzdem defekten Datenbank im Regen. So schauts aus.
Meine Frage, ohne erhobenen Finger: was soll ich dagegen tun?
Ich wundere mich gerade ebenfalls.
Hallo Robert,
sicherlich rettet man mit einer Sicherung keine bereits defekte DB.
Aber Du hast offenbar mit dem Sichern erst angefangen, als diese DB bereits zerschossen war. Die Sichern-Funktion gibt es aber seit Ewigkeiten.Ich hatte übrigens nicht Dich allein gemeint. Ab und zu lese ich über zerschossene DBs anderer Nutzer. Dein Posting war nicht der Grund, sondern der Anlass meines erhobenen Zeigefingers.
Nix für ungut!
-
Kannst Du uns die mal zukommen lassen zum checken?
Servus Tom!
Ich mache folgendes:
) markiere die gewünschte Ziel-WP-Tabelle
) klicke auf Import (Diskettensymbol)
) Auswählen (1/4): Typ Daten: Automatic, Files: meine gewünschte *.grm-Datei
) Typ (2/4): Wegpunkte markiert
) Ziel (3/4): die gewählte Tabelle
) Fertigstellen (4/4): unknown type, can´t import this fileErgebnis siehe Anhang.
Danke & Gruß,
Robert -
könnte an der Endung *.grm liegen. Aus irgendwelchen Gründen schluckt die QV nicht.
Benenn die mal um auf *.wpt, dann sollte es gehen.
Tom -
könnte an der Endung *.grm liegen. Aus irgendwelchen Gründen schluckt die QV nicht.
Benenn die mal um auf *.wpt, dann sollte es gehen.
TomIch habe zwar nicht diese Datei umbenannt, aber eine vorhandene alte *. wpt funktioniert auch nicht.
Robert
-
Hallo Robert,
warum lädst Du nicht mal eine Datei hoch, wie ich bereits in Posting #6 geschrieben habe? -
... warum lädst Du nicht mal eine Datei hoch, wie ich bereits ... geschrieben habe?
Weil... ich diesen Beitrag schlicht und einfach übersehen habe
Hole ich hiermit nach, siehe Anhang. Ich musste die Datein aber umbenennen, weil *.wpt und *.grm ungültige Dateiformate sind und nicht hochgeladen werden können; also bitte das .jpg hintendran wieder entfernen!
Keine dieser drei Dateien konnte ich in QV7 importieren.Zum Backup:
natürlich sichere ich meine Daten, sogar ziemlich regelmäßig und doppelt (Server, NAS).
Bis kürzlich hatte ich noch die Sicherungen mehrere Monate zurück. Weil aber mein QV7 absolut problemlos lief, hatte ich beim Aufräumen die ältesten der Sicherungen bedenkenlos entsorgt.
Ich verwende QV oft und regelmäßig, aber leider hatte ich mich die letzten Monate scheinbar in allen anderen DB herumgetrieben, aber nicht in den beschädigten. Somit ist mir der Fehler auch nie aufgefallen, wie denn auch.
Es war wirklich Glück, dass ich in einem alten Ablage-Ordner noch Kopien der *.wpt und *.grm gefunden habe. Daraus konnte ich ja über den Umweg TTQV4 und Export als *gpx die verlorenen Daten wieder herstellen.Von daher ist ja nix passiert; die Marokko-Daten habe ich wieder und die zweite zerschossenen DB war nur eine allgemeine "Austausch"-DB und fehlt mir nicht.
Die DB ist ja auch nicht völlig weg, sondern nur eine Track-Tabelle (Error) und die WP-Tabelle (einfach leer); der Rest ist normal lesbar.Danke euch allen für eure Hilfe und den großartigen Job, den ihr hier macht!
Gruß,
Robert -
-
Danke, aber:
"Der Zutritt zu dieser Seite ist Ihnen leider verwehrt. Sie besitzen nicht die notwendigen Zugriffsrechte, um diese Seite aufrufen zu können."
Kann aber auch mit der Suche nach so einem Thema nichts finden.Gruß,
Robert -
Hole ich hiermit nach, siehe Anhang
Du bist ja ein alter Hase
Ist gefixt, ab der 25 können die gelesen werden.
Interne Verlinkung: 7.0.1.19 grm PCX5 Datei importieren
auch gefixt.
Tom
