PQ - Import Fehler (auch 500) - Bugfix/Patch entdeckt

[Der Gieger]

Zu früh gefreut. Heute musste der sdf-Viewer wieder weiterhelfen, da der Import der aktuellen myfinds-PQ abgebrochen ist. Nach der Reparatur klappte der Import wieder problemlos.

Kleiner Tipp: Nachdem die aktuelle Version 500 mir zu oft abgestürzt ist, bin ich erst einmal zur 496 zurückgegangen. Ein Löschen von cachebox.sdf und ein Neustart von CB mit anschliessendem sofortigem Beenden lässt die hartnäckig verbliebene Titelzeile verschwinden. Ein Reset des Gerätes räumt dann die Speicherleichen beiseite. Danach habe ich mir angewöhnt, die "gute" Datenbank vor Importen umzubenennen oder zu kopieren. Schlägt der Import in eine neue leere DB fehl, geht nichts kaputt. Wer auf diese Weise sich verschiedene DB's schaffen will, etwa für spezielle Reiseziele, kann das auch so machen. CB stört das nicht. Sie arbeitet einfach immer nur mit cachebox.sdf. Fehlt diese, wird sie erstellt.

 

[GeoSilverio]

Ich habe zwar keine Import- oder Absturz-Probleme, nutze aber auch mehrere Datenbankfiles, da ich sonst einfach zuviel Caches in einer DB habe, die ich nur in bestimmten Regionen brauche.
So habe ich ein DB-File für die Home-Region, eines für meine alte Heimat, in der ich aber öfters bin und cache und dann meist noch eine für einen Urlaub... Ach ja, auch noch eine Test-DB für Tests und Recherchen fürs Forum.

Die Datenbankfiles liegen alle auf der SD-Karte und haben entsprechende Dateinamen.
Z. B.: cachebox_hh.sdf für die Hamburger Region.
Dazu hab ich mir mit Mortscript ein kleines Progrämmchen geschrieben, das mir die Regionen zur Auswahl bringt und nach Antippen der Region dann den entsprechenden DB-Filenamen in die cachebox.config schreibt und anschließend cachebox dann auch startet.

 

[FlashCool]

Seit heute habe ich auch Probleme gpx-Dateien in Cachebox zu importieren. Erst dachte ich, es liegt am gpx-Format, d.h. in der Datei ist ein Fehler enthalten. Nachdem ich aber diverse gpx-Dateien versucht habe zu importieren (Direkt-Download eines einzelnen Caches via gpx-Datei von gc.com; gpx-Datei aus GSAK erzeugt), vermute ich meine DB ist defekt.

Komischerweise lassen sich bereits in Cachebox bestehende Caches aktualisieren.
Neue Caches, d.h. die noch nicht in der Cachebox-DB vorhanden sind, lassen sich nicht importieren bzw. anlegen. Aber neue Wegpunkte manuell in CB anzulegen, geht wiederrum.

Hier mal die Fehlermeldung beim Import:

System.Exception: Failed to parse GPX.
Cachebox.Geocaching.GpxImport.ImportGpx(String[] files) bei Cachebox.FormImportPocketQuery.threadEntryPoint()

Cachebox Version: 500
Windows Mobile 6.5 auf HTC HD mini

Beispiel-gpx-Dateien, die nicht funktionieren habe ich mal beigelegt.

Kann mir jemand weiterhelfen?

 

[FlashCool]

Habe das Import-Problem mittlerweile Lösen können

Ursache war ein Problem mit der SQL-Datenbank Datei. Wie hier bereits im Thread angesprochen, habe ich auch das Tool SDF Viewer benutzt, um die sdf-Datei am PC einzulesen. Dabei habe ich die beiden Funktionen "Repair" sowie "Compact" verwendet.

"Repair" brachte zunächst keine Änderung, erst nach "Compact" und anschließendem Ersetzen der Orginal-DB cachebox.sdf funktionierte der Import wieder fehlerfrei.

Warum allerdings die DB "korrupt" war, ist mir ehrlich gesagt schleierhaft.
Es gab zuvor keine Abstürze unter Windows Mobile und auch Cachebox ist nicht hängengeblieben oder abgestürzt.

Die DB war vor dem "Compact" 192 MB groß, danach 192 MB und umfasst ca. 2200 Caches. Also nichts ungewöhnliches, einige haben ja deutlich mehr Datensätze in Benutzung.

Kann sich dieses "Verhalten" jemand erklären?
Ich weiss, ist nicht unbedingt eine Sache von Cachebox - aber um das zukünftig zu vermeiden, wäre es nicht schlecht zu wissen, warum auf einmal die DB ein Problem hatte.

 

[Der Gieger]

Cachebox braucht Einiges an Arbeitssspeicher und der ist bekanntlich sehr begrenzt. Im Bezug auf die "allgemeine Trägheit" des Gerätes (da hatte ich CB noch gar nicht drauf) habe ich nach Einträgen im Autostart-Ordner gesehen und bin sehr wohl fündig geworden. Mein glofiish X650 lädt von Haus auf einen Skype-Dienst mit, auch wenn man den gar nicht benötigt. Ebenso noch einige schlecht programmierte und für mich verzichtbare Gimmicks. Was in den Hauptspeicher installiert wurde, belegt den. Also auch mal hier ausmisten. Das Schöne an meinem Gerät: ich kann das jederzeit wieder installieren. Ist ein Programm abgestürzt oder meldet zum Schluss einen "unerwarteten Fehler", ist der RESET-Knopf des Gerätes immer das Beste. Irgendwas werkelt oft unkontrolliert im Speicher, frisst Resourcen und verbraucht die Batterie. Ich hatte mal einen Absturz, habe das nicht gemacht und hatte am nächsten Tag ein heisses Gerät und eine fast leere Batterie. Ein unkontrollierter Prozess schreibt auch gern mal Daten in Speicherbereiche, die ihm gar nicht mehr gehören. Windows mobile kümmert sich nicht um solche Sachen im Gegensatz zu seinem grossem Bruder auf dem PC. Bei Manchem mag so etwas der eigentliche Auslöser gewesen sein. Allerdings: Cachebox prüft zu wenig die Daten auf Richtigkeit, bevor es sie in die DB schreibt. Sonst käme so manche kryptische Fehlermeldung nicht. Auch werden offenbar gleiche Datensätze (zwei oder mehr identische Caches mit der gleichen Nummer) angenommen und führen erst später, etwa beim Filtern, zu einem Datenbankfehler mit Absturz. Jedoch sollte jedes Cache nur einmal angenommen werden, bei einem weiteren Versuch gäbe es die Möglichkeit eines Updates, des Ignorierens oder schreibens in eine "DENIED.DB" etc. Genauso die Sache mit dem Datum: Ich habe mir wieder mal mit GCzII GPXen gemacht und importiert. Da das Programm nur mit englischer Einstellung der GC-Seite arbeitet, ist das Datumsformat englisch. Ein solches Datumsformat sollte aber schon behandelt werden können.

 

[GeoSilverio]

Also mit Speicher hatte ich bislang wenig Probleme. Allerdings habe ich auch ein HD2, also auch nicht arg viel internen Speicher aber immerhin 448 MB.
Zum Import würde ich eher sagen, dass cachebox eher zu stark auf die Richtigkeit der Daten prüft. Eine etwas weichere Prüfung, wäre an einigen Stellen schöner.

Das mit dem Datumsformat kann ich nicht nachvollziehen.
Das Datumsformat ist doch (wenn ich richtig weiß) vorgegeben, oder? Egal mit welcher Sprache, Ländereinstellung etc. ich arbeite.
Bei mir sieht das beispielsweise immer so aus:
<time>2006-10-04T08:00:00Z</time>
bzw. in Logs etc. dann so:
<groundspeak:date>2010-09-12T19:00:00Z</groundspeak:date>

GCzII macht mir daraus dann sowas:
<time>T00:00:00.0000000-00:00</time>

Vielleicht hab ich aber auch nur was falsch eingestellt in GCzII, ich hab das Programm zwar drauf, nutze es aber fast nie.

 

[Der Gieger]

Also mit Speicher hatte ich bislang wenig Probleme. Allerdings habe ich auch ein HD2, also auch nicht arg viel internen Speicher aber immerhin 448 MB.
Zum Import würde ich eher sagen, dass cachebox eher zu stark auf die Richtigkeit der Daten prüft. Eine etwas weichere Prüfung, wäre an einigen Stellen schöner.

Das mit dem Datumsformat kann ich nicht nachvollziehen.
Das Datumsformat ist doch (wenn ich richtig weiß) vorgegeben, oder? Egal mit welcher Sprache, Ländereinstellung etc. ich arbeite.
Bei mir sieht das beispielsweise immer so aus:
<time>2006-10-04T08:00:00Z</time>
bzw. in Logs etc. dann so:
<groundspeak:date>2010-09-12T19:00:00Z</groundspeak:date>

GCzII macht mir daraus dann sowas:
<time>T00:00:00.0000000-00:00</time>

Vielleicht hab ich aber auch nur was falsch eingestellt in GCzII, ich hab das Programm zwar drauf, nutze es aber fast nie.

Also bei GCzII kann man in Sachen Datum gar nichts einstellen. Der Import der Caches mit dem falschen Datumsformat funktioniert zwar, aber wenn man das "Fortschrittsfenster" verfolgt, kommt der Hinweis schon. Vielleicht liegt es an der regionalen Einstellung von WIN mobile, nur daran will ich jetzt nicht schrauben. Wenn die englisch eingestellt wäre, ginge es dann sicher wieder.
Ein Import in eine Datenbank muss generell immer geprüft werden. Versuche, beliebige Zeichen in ein Feld, das nur Zahlen aufnehmen soll zu schreiben, müssen ebenso im Vorfeld unterbunden werden, wie einen doppelten Wert in ein Feld zu schreiben, in dem jeder Wert nur einmal vorkommen darf.
Würde wirklich richtig geprüft, käme kein Datenbankfehler, sondern eine vom Programmierer geschriebene Meldung, die wesentlich lesbarer ist. Solche Meldungen hingegen sind echte Laufzeitfehler.
Die Sache mit den doppelten Caches ist hingegen wohl sogar gewollt? Ich habe mir die Struktur der Datenbank in einem Tool von MS angesehen und festgestellt, dass ein anderes Feld den Index hat. Es hängt wohl damit zusammen, dass Caches auch nach GPX-en gefiltert werden können. Überlappt sich da ein Bereich, ist alles daraus doppelt.

 

[cacheboxer]

Hallo Der Gieger,

ich kann dem Thread irgendwie gar nicht entnehmen, was eigentlich Dein Problem ist?

Also bei GCzII kann man in Sachen Datum gar nichts einstellen. Der Import der Caches mit dem falschen Datumsformat funktioniert zwar

Wann hast Du wie welches Problem mit einem Datum?

Zeichen in ein Feld, das nur Zahlen aufnehmen soll zu schreiben, müssen ebenso im Vorfeld unterbunden werden

Beispiel?

wie einen doppelten Wert in ein Feld zu schreiben, in dem jeder Wert nur einmal vorkommen darf. Würde wirklich richtig geprüft, käme kein Datenbankfehler

Wann kommt denn welcher Datenbankfehler?

Die Sache mit den doppelten Caches ist hingegen wohl sogar gewollt? Ich habe mir die Struktur der Datenbank in einem Tool von MS angesehen und festgestellt, dass ein anderes Feld den Index hat. Es hängt wohl damit zusammen, dass Caches auch nach GPX-en gefiltert werden können. Überlappt sich da ein Bereich, ist alles daraus doppelt.

Gib auch hier 'mal ein Beispiel. Primary Key ist ein Hash vom <name> (GC-Code) des Caches, der bei Caches der mir bekannten Geocaching-Plattformen eigentlich eindeutig sein sollte. Dass nicht der GC-Code selbst der Primary Key ist, wird seinen Grund haben, sonst hätte sich hannes! sich nicht die Mühe gemacht, einen zusätzlichen Schlüssel zu berechnen.
Dass das irgendwas mit dem GPX-Filter zu tun hat, glaube ich nicht. Zu jeden Cache ist vermerkt, aus welcher GPX er kommt - was soll sich da überlappen?

MfG

 

[Der Gieger]

Hallo Der Gieger,

ich kann dem Thread irgendwie gar nicht entnehmen, was eigentlich Dein Problem ist?

Also bei GCzII kann man in Sachen Datum gar nichts einstellen. Der Import der Caches mit dem falschen Datumsformat funktioniert zwar

Wann hast Du wie welches Problem mit einem Datum?

Zeichen in ein Feld, das nur Zahlen aufnehmen soll zu schreiben, müssen ebenso im Vorfeld unterbunden werden

Beispiel?

wie einen doppelten Wert in ein Feld zu schreiben, in dem jeder Wert nur einmal vorkommen darf. Würde wirklich richtig geprüft, käme kein Datenbankfehler

Wann kommt denn welcher Datenbankfehler?

Die Sache mit den doppelten Caches ist hingegen wohl sogar gewollt? Ich habe mir die Struktur der Datenbank in einem Tool von MS angesehen und festgestellt, dass ein anderes Feld den Index hat. Es hängt wohl damit zusammen, dass Caches auch nach GPX-en gefiltert werden können. Überlappt sich da ein Bereich, ist alles daraus doppelt.

Gib auch hier 'mal ein Beispiel. Primary Key ist ein Hash vom <name> (GC-Code) des Caches, der bei Caches der mir bekannten Geocaching-Plattformen eigentlich eindeutig sein sollte. Dass nicht der GC-Code selbst der Primary Key ist, wird seinen Grund haben, sonst hätte sich hannes! sich nicht die Mühe gemacht, einen zusätzlichen Schlüssel zu berechnen.
Dass das irgendwas mit dem GPX-Filter zu tun hat, glaube ich nicht. Zu jeden Cache ist vermerkt, aus welcher GPX er kommt - was soll sich da überlappen?

MfG

Also, die GPX hat es ja importiert, aber während des Importes kommt in dem Meldungsfenster eben der Hinweis mit dem falschen Datumsformat. Für mich hat sich dieses Problem aber erledigt, da ich meine GPXen jetzt mit Cachewolf erstelle und die werden ohne Murren angenommen. Ausserdem bin ich von Version 496 auf 500 gegangen.
Ein Beispiel zu "

Zeichen in ein Feld, das nur Zahlen aufnehmen soll zu schreiben, müssen ebenso im Vorfeld unterbunden werden

" kann ich nicht liefern. Ich hatte mich hiermit nur auf die Prüfung des Datumsformats bezogen und dabei etwas unglücklich formuliert.
Q: Dass das irgendwas mit dem GPX-Filter zu tun hat, glaube ich nicht. Zu jeden Cache ist vermerkt, aus welcher GPX er kommt - was soll sich da überlappen?: Mit "überlappen" meine ich folgendes:
Erzeuge eine GPX vom einem Ort mit einem Umkreis von z.B. 5km. Mach eine Zweite vom Nachbarort in 3km Entfernung. Importiere beide. Die Schnittmenge ist die Überlappung.

 

[cacheboxer]

Sorry, aber ich versteh's immer noch nicht...

Bei mir gibt's keine Überlappung, obwohl ein und derselbe Cache in mehreren PQs vorkommt. Selbstverständlich ist der dann nur einmal in der DB.

MfG

 

[GeoSilverio]

Ich vermute da gibts eine Differenz in der Cachebeschreibung...
Vielleicht heißt ein und der selbe Cache in der einen GPX anders, als in der anderen?
Ich weiß nicht genau, woran cachebox das festmacht, ich vermute mal der GC-Code des Caches ist das ausschlaggebende.

 

[Der Gieger]

Wie gesagt, ich habe ja alles frisch neu installiert, auch CB in der aktuellen Version 500 die bisher bei mir nicht wollte. Bisher läuft alles gut, außer man kommt auf den "Aus-Schalter" am Gerät. Das läßt sich aber verschmerzen.
Übrigens, ich habe den Grund gefunden, warum die 500er Version nicht lief. Ich hatte seperat das .NET Framework installiert. Da das aber bereits bei CB im Anwendungsbundle in der CAB-Datei enthalten ist, gab es wohl ein paar Versionskonflikte wegen doppelter Laufzeitbibliotheken. Also, wer beim Start gleich schwerwigende Fehler gemeldet bekommt sollte unter "Einstellungen - Software entfernen" mal nachsehen, ob dort .NET Framework 3.5 zu finden ist. Wenn ja, dann raus damit!