Wer kennt es nicht das Problem. Man hat 2-3 Wochen bzw. 50 Caches lang keine Statistik mehr generiert und dann nachdem man mal wieder die Graphiken aktualisert hat, kommt das Horrorszenario: 2047 Funde bei 2046 Caches.
Abbildung 1: Der Horror - Bei einem Cache hab ich aus versehen doppelt geloggt
OK, es müssen nicht genau 2047 Funde sein, aber das Problem hatten die meisten schonmal. Bei irgendeinem Cache ist doppelt geloggt wurden. Entweder hat der Groundspeak Server gehangen und man hat doppelt losgeschickt, man hat einmal vom Smartphone und einmal am PC geloggt oder beim nachträglichen Ändern des Logs (Text / Datum) ist was schiefgegangen.
Schlimmer als die Frage
WARUM ist "
WO habe ich doppelt geloggt?"
Da kann es schon ein wenig mühselig sein die letzten 50 Caches durchzugehen. Vorallem wenn man zwischendurch ganz alte Einträge nachholt. "Ach ja, das Event von letztem Jahr muss ich auch noch nachloggen."
Abbildung 2: Sqlite Manager als Datenbank-Tool starten
Aber warum soll man selber suchen und nicht suchen lassen.
Anmerkung: Nach Veröffentlichung des Posts wurde ich durch Kommentare aufmerksamer Leser darauf hingewiesen, dass man das Problem mittlerweile durch GSAK-Bordmittel lösen kann. (Siehe Kommentare). Hier erfolgt der Ansatz über die Datenbank, der für das Doppelte-Logs-Problem etwas komplizierter ist, dafür aber einen guten Einstieg gibt, wie man Infos aus der zugrunde liegenden Datenbank sqlite ziehen kann
Wir werfen dazu einen Blick auf die Datenbank, genau genommen der Datenbestand, der alle Founds enthält und von wo aus die Statistik generiert wird.
Um einen direkten Datenbankzugriff zu bekommen nutzen wir das von GSAK mitgelieferte Tool
Sqlite Manager.
Dies ist über
Tools in der Menüleiste zu erreichen.
Wer mit alternativem Tools wie z.B. DBVisualizer unterwegs ist kann auch direkt die Sqlite Datei .db3 öffnen aber das GSAK integrierte Tool tut es hier vollkommen.
Abbildung 3: Die richtige Datenbank auswählen
Wichtig ist, dass ihr die richtige Datenbank auswählt. Bei mir heißt die Datenbank für die Funde
foundDB, folglich liegt die Datenbankdatei unter
data/foundDB/sqlite.db3
Abbildung 4: Durch geschickten Select auf die Logs Tabelle bekommt man alle doppelten Einträge heraus
Sobald die richtige Datenbank geöffnet ist, geht es los.
Zuerst selektiert man alle Zeilen deren Log-Type
Found it und deren Finder man selbst ist.
Krolock müsst ihr natürlich durch Euren Nickname ersetzen, ansonsten sehr ihr nur, ob ich doppelt geloggt haben
Um nicht mit unnötig vielen Daten weiterzuarbeiten wird nur die Spalte lParent geladen. Dies ist der GCCode des Caches den ihr gefunden habt.
Der SQL-Befehl lautet bisher
SELECT lParent FROM Logs where lType = 'Found it' and lBy = 'Krolock'
Es müssten nach unserem Beispiel 2047 Zeilen ausgegeben werden.
Jetzt kommt der entscheidene Schritt, die Gruppierung. Dazu ergänzen wir im select Part ein Count(*) und gruppiern auf lParent
SELECT count(*) c, lParent FROM Logs where lType = 'Found it' and lBy = 'Krolock' group by lParent liefert nun 2046 Zeilen bei dem überall die Zählspalte c den Wert 1 besitzt.
"Ganz Gallien?" - Nein in einer Zeile steht ein 2, das ist die gesuchte Zeile.
Um die Einserwerte zu eleminieren bauen wir noch ein Select um das Zwischergebnis herum, indem wir mit
where c > 1 nur die Mehrfachnennungen aufzeigen und -falls ihr so richtig Mist beim Loggen hinbekommen habt- sortieren wir noch nach c absteigend
Zu kompliziert?
Solltest du jetzt denken
" .... HÄ ???? .... ", so kann ich dich beruhigen.
Nimm einfach folgenden Code und ersetzte
Krolock durch deinen Nickname.
Drücke dann auf F9 und schon siehst du den GCCode der Caches bei denen du doppelt geloggt hast.
select * from (SELECT count(*) c, lParent FROM Logs where lType = 'Found it' and lBy = 'Krolock' group by lParent) where c > 1 order by c desc
