Fragen zum Multi-DB-Support

Ich habe mit in der neuesten Vorabversion (neue 533er vom 13.02.) mal den Multi-DB-Support etwas angeschaut.

Ausgehend von Funktionalitäten, die vor allem "Der Gieger" mit seinen Scripten umgesetzt hatte, wäre eine Sache wünschenswert (auch in Win-CB)...

Beim Start fragt CB ja nach, welche Datenbank gestartet werden soll, wenn mehr als eine DB im Pfad gefunden wird. (Da gabs ja noch ein Problem, dass immer das DB-Verzeichnis verwendet wurde, nicht der in der config eingestellte Pfad, das habe ich aber jetzt nicht ausprobiert...)
CB startet dann mit der gewählten Datenbank.
Soweit funktioniert alles.

Wünsche:
1. Es wäre schön, einen Alias für gefundene Datenbank angeben zu können. Und sei es Manuell in der config oder so. Also in etwa sowas:
cachebox_bln.sdf=Berlin
cachebox_htpf=Hintertupfingen
....

2. Um die Images besser verwalten zu können, wäre es schön, auch den Images-Pfad irgendwie variabel halten zu können. Da weiß ich aber nicht, wie das umgesetzt werden könnte.
Begründung: Man erstellt sich oftmals eine neue DB für ein ganz spezielles Gebiet. Sagen wir mal, für einen Urlaub... Nun wird eine Datenbank erstellt mit den Caches der Urlaubsregion. Die Bilder landen aber alle im Images-Ordner.
Ist der Urlaub nun vorbei, alle Cachenotes hochgeladen, kann die DB meist gelöscht werden. Die Bilder bleiben aber damit sinnlos im Images-Ordner.
Ich glaube durch aktives Löschen aller Caches dieser Datenbak würden zwar auch die Bilder gelöscht, einfach wäre es aber, einfach db-File und den relevanten Images-Ordner zu löschen, fertig....
In einem Mortscript hatte ich das so gemacht (und "Der Gieger" in seinem umfangreichen Paket wohl auch), dass ich vor dem Start abfragte, welche DB geladen werden soll. Je nach Auswahl hat das Script dann den DB-Namen und auch den Images-Ordner-Namen angepasst.
Um also beim Beispiel oben zu bleiben:
Auswahl Berlin:
DatabasePath=C:\Program Files (x86)\WinCachebox\cachebox_bln.sdf
DescriptionImageFolder=C:\Program Files (x86)\WinCachebox\Repository\Images_bln
Auswahl Hintertupfingen:
DatabasePath=C:\Program Files (x86)\WinCachebox\cachebox_htpf.sdf
DescriptionImageFolder=C:\Program Files (x86)\WinCachebox\Repository\Images_htpf
...
Irgend sowas in der Art.

Vielleicht gibt es auch viel elegantere Lösungen für das Thema?
Das ist das, was mir aufgrund existierender Lösungen mit Scripten eben so einfällt.

P.S.: Falls gewünscht, trage ich das auch gerne in Sourceforge im Ticketsystem ein, auch in Englisch. Ich will halt erst mal die Meinung der User hören!

Es wäre sicherlich sinnvoll, wenn das Verzeichnis für die Bilder
irgendwo in der Datenbank gespeichert würde.
So könnten nicht mehr benötigte Bilder (Urlaubsdatenbank)
gelöscht werden...

Wie funktionieren eigentlich Fieldnotes wenn ich mit mehreren Datenbanken arbeite? Ich habe vor einigen Monaten mal einen Versuch gemacht und die db immer umbenannt. Dabei habe ich dann festgestellt dass, nachdem ich wieder auf die alte db1 zurückgewechselt habe, die in der anderen db2 eingegebenen fieldnotes nicht mehr da waren und statt dessen die Fieldnotes aus db 1 wieder angezeigt wurden.

Ist es mit dem Multi DB Support dann so, dass die Fieldnotes von der db unabhängig erfasst werden und alle in einer gemeinsamen geocache_visits.txt landen?

Viele Grüße
Christian

Die FieldNotes werden in der Datenbank gespeichert. Für die Funktion "Upload FieldNotes" fände ich das jetzige Verhalten gerade noch OK und argumentierbar, bei der fieldnotes.html wird das schon schwieriger und bei der geocache_visits.txt passt es dann gar nicht mehr.

Die FieldNotes sollen ja die Reigenfolge der Logs korrekt wiedergeben, damit Meilenstein-Freunde brauchbaren Input für Ihre Statistik bekommen...

cacheboxer schrieb:

Die FieldNotes sollen ja die Reigenfolge der Logs korrekt wiedergeben, damit Meilenstein-Freunde brauchbaren Input für Ihre Statistik bekommen...

Zum Vergrößern anklicken....

Gut das CB für mich überwiegend NUR eine DB ist und ich meinen Oregon550 habe. Da stehen in der geocache_visits.txt ALLE gefundenen Caches drin (zwischen den Anführungszeichen der jeweilige Cachename) ...
ICH lege Wert auf Reihenfolge und Vollständigkeit, ohne den Anspruch auf Meilensteinfanatiker oder Statistiker zu erheben

Ich glaube der Status des Caches wird in der Db gespeichert, die fieldnotes selbst aber nicht.
Auf jeden Fall gibts da noch ein "Delta", was den Multi-DB-Support angeht.

Dass sich die verschiedenen Datenbanken, was den Status eines Caches angeht, untereinander automatisch abgleichen, halte ich für übertrieben.
Wenn ich einen Cache identisch in 2 verschiedenen Datenbanken habe, und in einer DB auf "Found" setze, ist er in der anderen eben nicht mit dem Status versehen, bis ich das manuell nachhole oder eine neue GPX importiere.
Das ist aber auch OK so...

Das andere sind eben die geocache_visits.txt-Files.
Mit dem Multi-DB-Support gibts es pro Datenbank eine eigene Datei. Das ist tödlich.
Ich würde vorschlagen, das wie gehabt in eine gemeinsame Textdatei rein zu schreiben und gut ist. Dann passt ja wieder alles.
Für die Reihenfolge, in der mal die Logs macht oder dann auch in gc.com übernimmt, ist man schon selbst zuständig...

Ich denke ich werde mal die Punkte von hier zusammenfasse, ins englische bringen und in sourceforge einstellen.

Die Reihenfolge der gefunden Caches lässt sich einfach nachvollziehen, wenn man die Fundanzahl #finds# in die Fieldnote schreiben lässt. Wenn jetzt die geocaches_visits.txt unabhängig von der geöffneten Datenbank geschrieben würde, sollte es eigentlich keine Probleme geben.

Viele Grüße
Christian

Leider geht das so nicht bzw. nicht befriedigend.
Da man ja zwei geocache_visits.txt-Files hat, muss man die nacheinander hoch laden.
Hat man nun in DB1 zwei logs von Samstag, in DB2 dann zwei Logs von Sonntag und in DB1 dann wieder ein paar logs von Montag und lädt nun erst die visits.txt von DB1 hoch und danach die von DB2, erscheinen die logs aus DB2 überhaupt nicht.
Man kann zwar in gc.com einstellen, dass er sich um so poplige Sachen, wie Datum und Zeitstempel des logs nicht kümmern soll, dann kommen aber, falls die visits.txt nicht leer war, auch alle alten logs wieder in die Fieldnotes-Übersicht von gc.com.

Ich würde einfach sagen: Es soll alles in eine Datei geschrieben werden und fertig.
Zudem spart man sich, jeweils jede DB zu laden, dann den upload zu machen, dann db wechseln, dann wieder upload machen.....

Klar, wird man hier auch jemanden finden der meint: Ich will aber immer nur die logs von DB1 hoch laden und NIE die logs von DB2....

Genau so hatte ich das auch gemeint, egal wieviele db verwendet werden, die Funde müssen alle in eine gemeinsame geocache_visits.txt geschrieben werden.

Viele Grüße
Christian

Silverio schrieb:

Ich glaube der Status des Caches wird in der Db gespeichert, die fieldnotes selbst aber nicht.

Zum Vergrößern anklicken....

Wenn ich mich recht erinnere, stehen die Field Notes in der DB um daraus die fieldnotes.html zu erzeugen. Bei einer html-Datei kann man ja nicht so ohne Weiteres "hinten anhängen" und ausserdem steht der zuletzt gefundene Cache ja immer oben.

Ob die Field Notes noch zu einem anderen Zweck gespeichert werden, weiß ich allerdings nicht.

Wenn ich einen Cache identisch in 2 verschiedenen Datenbanken habe, und in einer DB auf "Found" setze, ist er in der anderen eben nicht mit dem Status versehen, bis ich das manuell nachhole oder eine neue GPX importiere.

Zum Vergrößern anklicken....

... und dadurch den Fundzähler erhöhst, in dem der Cache aber aber schon aus der ersten DB berücksichtigt ist

cacheboxer schrieb:

Wenn ich einen Cache identisch in 2 verschiedenen Datenbanken habe, und in einer DB auf "Found" setze, ist er in der anderen eben nicht mit dem Status versehen, bis ich das manuell nachhole oder eine neue GPX importiere.

Zum Vergrößern anklicken....

... und dadurch den Fundzähler erhöhst, in dem der Cache aber aber schon aus der ersten DB berücksichtigt ist

Zum Vergrößern anklicken....

Wobei ich da jetzt erst mal sagen würde:
Als erstes sollte das visits.txt-handling korrigiert werden.

Wer in mehreren Datenbanken den gleichen Cache hat und ihn in allen DB als found logged, ist halt erst mal selbst schuld.

Typischerweise macht man mehrere Datenbanken ja zu verschiedenen Regionen oder mal zu testzwecken.

Silverio schrieb:

cacheboxer schrieb:

Wenn ich einen Cache identisch in 2 verschiedenen Datenbanken habe, und in einer DB auf "Found" setze, ist er in der anderen eben nicht mit dem Status versehen, bis ich das manuell nachhole oder eine neue GPX importiere.

Zum Vergrößern anklicken....

... und dadurch den Fundzähler erhöhst, in dem der Cache aber aber schon aus der ersten DB berücksichtigt ist

Zum Vergrößern anklicken....

Wobei ich da jetzt erst mal sagen würde:
Als erstes sollte das visits.txt-handling korrigiert werden.

Zum Vergrößern anklicken....

Das sehe ich auch so.

Wer in mehreren Datenbanken den gleichen Cache hat und ihn in allen DB als found logged, ist halt erst mal selbst schuld.

Zum Vergrößern anklicken....

Geht ja nicht nur um's manuelle "Nachholen" (s.o. ) - beim GPX-Import können ja auch Funde reinkommen.
Mir persönlich ist das herzlich wurscht - heutzutage loggt aber ja fast jeder Zweite mit der Fundnummer im Log und diese Zielgruppe dürfte was die Zahlen angeht, recht anspruchsvoll sein.

Hab selbst mit der FieldNote Funtion von CB bisher noch nichts gemacht. Bin (noch) kein PowerCacher...

Hab aber jetzt mal versucht nachzuvollziehen, wie CB die FieldNotes momentan verwaltet:

• In jeder DB (Multi-DB) ist eine Tabelle "FieldNotes". Darin werden die Fieldnotes dieser DB gespeichert.
• Aus dieser Tabelle werden dann die visits.txt und die fieldnotes.html erzeugt. Den Dateinamen wird jetzt (Multi-DB) jeweils der Dateiname der DB-Datei vorangestellt.
• Die visits.txt und die fieldnotes.html werden jedesmal komplett neu aus den Daten der Fieldnotes Tabelle der aktuellen DB erzeugt.
• Beim Upload über das Tools-Menü werden nur die Fieldnotes der aktuellen DB übertragen.
• Neu seit gestern (von hulkman) ist eine Einstellung, mit der verhindert werden kann, dass das Datum beim Upload überprüft wird. Dadurch wäre es möglich, Fieldnotes aus mehreren DB's nacheinander zu übertragen, selbst wenn sich die Daten (Datums?) überschneiden. Hat aber (wie hier schon berichtet) den Nachteil, dass dann immer wieder alle Fieldnotes übertragen werden. Also auch nicht unbedingt die beste Lösung.

Der einfachste Lösungsansatz wäre der, jedesmal beim Erstellen einer Fieldnote diese direkt an eine von allen DB's gemeinsam genutzte visits.txt anzuhängen. Den restlichen Inhalt immer einfach zu lassen. Dadurch könnte man dann alle Fieldnotes aller DB's nacheinander sammeln. Die Reihenfolge von Datum und Uhrzeit sollte dann auch passen (wäre aber gar nicht so wichtig).
Wird ein Cache zuerst als "DNF" geloggt und später als "Found!", dann wären in der visits.txt aber beide Einträge enthalten (momentan würde in diesem Fall der "DNF"-Eintrag überschrieben). Wäre dies ein Problem? Der Upload zu GC.com funktioniert. Dann werden beide angezeigt. Habs probiert.
Beim übertragen der Fieldnotes zu GC.com würden dann (unabhängig von der aktuellen DB) immer alle Fieldnotes aller DB's übertragen.

Ein Erweitern der fieldnotes.html auf diese Weise dürfte allerdings nicht so einfach sein. Wozu braucht man diese Datei überhaupt? Nur zur Anzeige aus CacheBox heraus? Aber diese html könnte ja so bleiben wie aktuell (jeweils eine für jede DB).

Was haltet ihr von dieser einfachen Lösung?

Als Alternative würde nur der Weg bleiben, den Longri schon mal vorgeschlagen hat, eine eingene DB für die Fieldnotes zu erstellen. Würde dann mit Sicherheit funktionieren, ist halt viel mehr Aufwand.

Ich würde das sogar noch ein wenig abwandeln(erweitern). Jedes Mal, wenn ein Cache ein Found abkriegt, dann könnte dieser Cache mit allen Dingen, die dazu gehören incl. Fieldnotes etc. in eine dedizierte einmalige "Founds"-DB verschoben werden. Dadurch lassen sich alle beschriebenen Probleme bzgl. Anzahl founds, Fieldnotes, etc. lösen.
Zusätzlicher Vorteil: Ich kann meinen Mitcachern spontan und zu jeder Zeit als Telefonjoker dienen und meine Wegpunkte Notizen etc. Kundtun!
OK oder Denkfehler?

Harry1999 schrieb:

Ich würde das sogar noch ein wenig abwandeln(erweitern). Jedes Mal, wenn ein Cache ein Found abkriegt, dann könnte dieser Cache mit allen Dingen, die dazu gehören incl. Fieldnotes etc. in eine dedizierte einmalige "Founds"-DB verschoben werden. Dadurch lassen sich alle beschriebenen Probleme bzgl. Anzahl founds, Fieldnotes, etc. lösen.
Zusätzlicher Vorteil: Ich kann meinen Mitcachern spontan und zu jeder Zeit als Telefonjoker dienen und meine Wegpunkte Notizen etc. Kundtun!
OK oder Denkfehler?

Zum Vergrößern anklicken....

Das finde ich eine sehr gute Idee!

Ich bin zwar nicht an dem MultiDB Änderungen beteiligt, ich denke aber wenn Ging-Buh sich mit hulkman in Verbindung setzt, ist diese Aufgabenstellung zu lösen.

In dieser FoundsDB könnte ja auch ein Offset sein falls jemand mit über 1000 Founds nicht alle mitschleppen möchte.


Gruß Longri

Harry1999 schrieb:

OK oder Denkfehler?

Zum Vergrößern anklicken....

Grundsätzlich wäre das schon OK.
zwei Sachen gibt es zu bedenken:
1. Du schreibst etwas davon, dass die Caches dann "verschoben" werden sollen.
Kann man so machen, allerdings sieht man dann in der aktuellen DB nicht, dass es den Cache gibt / gab. Beim nächsten Import, wo der Cache vielleicht zufällig wieder dabei ist, ist er dann aber wieder drin.
Man müsste also diese spezielle Founds-DB intelligent in die jeweils aktivierte DB einbeziehen.

2. Wer sehr viele Caches gefunden hat, hat auch eine sehr große DB für seine Funde.
Klar, alte logs fallen raus, aber die Cachedescription hätte man wahrscheinlich dort dennoch gerne drin etc...
Ich kenne hier in der Gegend ein paar Cacher, die 8- bis 12tausend Finds haben...

Longri schrieb:

1. Du schreibst etwas davon, dass die Caches dann "verschoben" werden sollen.
Kann man so machen, allerdings sieht man dann in der aktuellen DB nicht, dass es den Cache gibt / gab. Beim nächsten Import, wo der Cache vielleicht zufällig wieder dabei ist, ist er dann aber wieder drin.
Man müsste also diese spezielle Founds-DB intelligent in die jeweils aktivierte DB einbeziehen.

Zum Vergrößern anklicken....

Ja, dass ist ein Punkt... bei einem Import müsste dann quasi erst in der founds-db nachgeschaut und dann je nachdem in der eigentlichen gespeichert oder eben nicht werden. Das hört sich langsam an...muss man gut verproben.

Longri schrieb:

2. Wer sehr viele Caches gefunden hat, hat auch eine sehr große DB für seine Funde.
Klar, alte logs fallen raus, aber die Cachedescription hätte man wahrscheinlich dort dennoch gerne drin etc...
Ich kenne hier in der Gegend ein paar Cacher, die 8- bis 12tausend Finds haben...

Zum Vergrößern anklicken....

erstens: *grins* die haben selber schuld... sollen halt was richtiges in ihrer Freizeit machen, Fenster putzen oder so /*grins*
zweitens: wer so viele founds hat, der will bestimmt nicht immer alle Smiliesdie Karte verdecken sehen. (ich sprech da teilweise und nur bedingt aus Erfahrung...immerhin vierstellig)
drittens: Longris Vorschlag mit dem Offeset klingt gut.

Alles nur einfach mal so reingeworfen...

Mir gefällt es sehr gut, wenn ich während eines Cacheausflugs die heutigen Funde auf der Karte als Smilies nachvollziehen kann.

Ich denke wenn für alle Datenbanken eine gemeinsamte geocache_visits.txt geführt würde, wäre das vollkommen ausreichend und würde die genannten Problemfälle abdecken.

Viele Grüße
Christian

Ging-Buh schrieb:

Was haltet ihr von dieser einfachen Lösung?

Zum Vergrößern anklicken....

Spontan würde ich sagen, dass die meine persönlichen Anwendungsfälle abdecken würde (zumindest könnte ich damit leben) und die so auch einem Neuanwender erklärbar ist.

Wird ein Cache zuerst als "DNF" geloggt und später als "Found!", dann wären in der visits.txt aber beide Einträge enthalten (momentan würde in diesem Fall der "DNF"-Eintrag überschrieben). Wäre dies ein Problem?

Zum Vergrößern anklicken....

In diesem Beispiel: Im Gegenteil - wollte ich schon öfters 'mal in den Tracker eintragen, dass das nicht so ist. Ich möchte eigentlich pro Cache und Art der FieldNote einen Eintrag - so wie es bei Needs Maintenance auch funktioniert. Aber: wenn jedes OK zu einer FieldNote einen Eintrag in der visits erzeugt, fände ich das mehr als lästig. Ich editiere bei Multis zwischendurch immermal die Found!-Note, wenn mir etwas auffällt ("S4 - genial!", "S5 - lose"), damit ich später beim Loggen die wichtigsten Stichpunkte im Logeditor habe. Diese Möglichkeit möchte ich nur sehr ungern verlieren.

Hab selbst mit der FieldNote Funtion von CB bisher noch nichts gemacht. Bin (noch) kein PowerCacher...

Zum Vergrößern anklicken....

Die Funktion ist auch für Genusscacher supertoll. Wie schrieb hannes! doch dazu:

hannes! (2009) schrieb:

Es gibt schon genügen "Schnell gefunden, danke!" oder "TFTC" Logs! Nimm Dir zu Hause etwas Zeit, trink ne Tasse Tee, lade deine Fieldnotes hoch, und lass die gesamte Tour nochmal revue passieren.

Zum Vergrößern anklicken....

Ein Erweitern der fieldnotes.html auf diese Weise dürfte allerdings nicht so einfach sein. Wozu braucht man diese Datei überhaupt?

Zum Vergrößern anklicken....

Zur Anzeige der letzten Notes (deshalb steht auch der jüngste Eintrag oben), für Plattformen (OC etc.), die keine FieldNotes kennen, als Backup, wenn der Upload nicht funktioniert. Ich persönlich könnte hier aber gut damit leben, wenn die Datei pro DB erstellt wird.

Silverio schrieb:

:
1. Du schreibst etwas davon, dass die Caches dann "verschoben" werden sollen.
Kann man so machen, allerdings sieht man dann in der aktuellen DB nicht, dass es den Cache gibt / gab. Beim nächsten Import, wo der Cache vielleicht zufällig wieder dabei ist, ist er dann aber wieder drin.

Zum Vergrößern anklicken....

Wenn in den PQ-Einstellungen angehakt ist, das nur nichtgefundene Caches in die PQ sollen, sollten sie je nach Log- bzw PQ-Erstellungsdatum auch nicht mehr auftauchen ...

Beispiel: Meine Tochter und ich sind Premium-Member. So teilen wir uns in zehn PQ`s rein am gleichen Tag. Was meine Tochter NICHT ich aber SCHON gefunden habe, kommt immer wieder neu rein. Dafür nutze ich die Visits.txt vom OREGON um GSAK damit zu zeigen, DIESE Caches habe ich schon gefunden! In dieser Visits.txt stehen alle MEINE GEFUNDENEN CACHES IN CHRONOLOGISCHER FOLGE (inkl. der Cachenamen in den Anführungszeichen).
Umgedreht machts meine Tochter mit ihrem COLORADO ....

Würde diese Datei von (W)CB beim Programmstart mit gelesen und wäre vollständig, könnte (W)CB einen gefundenen Cache automatisch ausblenden/verstecken unabhängig von der verwendeten DB. Und diesen auch bei Neuimport wieder als gefunden markieren, ohne die Gefundenen als PQ immer neu importieren zu müssen.