Fragen zum Multi-DB-Support

[Timo TA93]

Zusätzlicher Vorteil: Ich kann meinen Mitcachern spontan und zu jeder Zeit als Telefonjoker dienen und meine Wegpunkte Notizen etc. Kundtun!
OK oder Denkfehler?

Der Gedanke ist völlig OK ... ich handele nach dem gleichen Prinzip: " Hilf und dir wird geholfen"
Dafür hab ich mein Cachebuch und meine DB.

Wenn CB intelligent mit der DB umgeht und nicht gleich bei zwei Caches "zuviel" in die Knie geht, störts mich nicht, die GEFUNDENEN in einer DB mit den nichtgefundenen Caches zu haben. Ich kann ja "filtern" oder "ausblenden" ...

 

[Der Gieger]

Was haltet ihr von dieser einfachen Lösung?

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?

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...

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

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.

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

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.

Das klingt eher nach dem Bedarf an einem internen Memofeld mit individueller Übernahmemöglichkeit in andere Datenfelder, wie eben Logs.
Wenn ein Cache gefunden wurde, braucht es doch eigentlich keinen "Did not Found" oder "Need Maintainance" mehr- höchstens noch bei Stages, wenn nur ein Teil gefunden wurde. Seht Ihr das auch so?

 

[cacheboxer]

Das klingt eher nach dem Bedarf an einem internen Memofeld mit individueller Übernahmemöglichkeit in andere Datenfelder, wie eben Logs.
Wenn ein Cache gefunden wurde, braucht es doch eigentlich keinen "Did not Found" oder "Need Maintainance" mehr- höchstens noch bei Stages, wenn nur ein Teil gefunden wurde. Seht Ihr das auch so?

Nein, dass klingt nach Field Notes, so wie sie jetzt sind
Klar, DNF braucht man nach Fund nicht mehr (CB löscht zur Zeit dann auch die Found It Note), aber NM braucht man auch bei Fund.
Wichtig ist mir, dass ich weiterhin zwischen den WPs meine Found it Field Note ergänzen kann. DNF, NM und WN sind Sonderfälle, in denen ich gerne mit suboptimalen Lösungen leben kann.

 

[Timo TA93]

Hmmm, bin nicht der DB-Freak (oder Spezi), aber in MS Access kann man ja jedem DB-Eintrag einen "Schlüssel" zuweisen ... in unseren Falle wäre der GCxxxxx angebracht. Damit sollte es wohl möglich sein aus den Field Notes verschiedener DB`s eine gemeinsame geocache_visits.txt zu "basteln", die dann zu GC.com hochgeladen werden kann mit korrektem Datum und Reihenfolge ...

 

[Ging-Buh]

Wichtig ist mir, dass ich weiterhin zwischen den WPs meine Found it Field Note ergänzen kann. DNF, NM und WN sind Sonderfälle, in denen ich gerne mit suboptimalen Lösungen leben kann.

Wie kannst du momentan die Found it Field Note ergänzen? Wenn ich eine weitere Found It erzeuge, wird die vorherige ersatzlos gelöscht. Oder täusche ich mich?

Vielleicht wäre es wirklich das beste, man würde für die FieldNotes eine eingene Datenbank-Datei (z.B. FieldNotes.sdf) erzeugen, in die dann alle Multi-DB's ihre FieldNotes eintragen können. Aus dieser Fieldnote-DB könnte dann die visits.txt mit allen FieldNotes aller DB's in der richtigen Reihenfolge erzeugt werden. Eine gemeinsame FieldNotes.html zu erzeugen wäre dann auch möglich.

 

[Timo TA93]

Hallo Hubert,
hatte es erst heute abend in einem anderen Thread geposted ... braucht man wirklich die "field notes.html"? Schade, ich find auf die schnelle nicht mal meinen eigenen Beitrag
Doch gefunden: Seite ZWEI letzter Beitrag in desem Thread ...
Aber auf GC.com wird ja nur die "geocache_visits.txt" hochgeladen, da kommt drauf an...

Ich teste in den nächsten Tagen auf Tour deine/eure Änderungen bezüglich der geocache_visits.txt aus und berichte ...

 

[cacheboxer]

Wichtig ist mir, dass ich weiterhin zwischen den WPs meine Found it Field Note ergänzen kann. DNF, NM und WN sind Sonderfälle, in denen ich gerne mit suboptimalen Lösungen leben kann.

Wie kannst du momentan die Found it Field Note ergänzen? Wenn ich eine weitere Found It erzeuge, wird die vorherige ersatzlos gelöscht. Oder täusche ich mich?

Gelöscht wird nur bei DNF (bei Write Note und NM weiß ich's grad nicht). Found it bleibt definitiv stehen und kann editiert werden. Wenn das bei allen Logtypen so wäre, wäre die "einfache" Lösung eigentlich ganz OK. Der Field Note Dialog bei GC hat ja mittlerweile eine Bulk Delete-Funktion. Man könnte dann einfach die überschüssigen Notes weglöschen und hätte alle Infos in der jeweils letzten Note pro Cache und Typ.

Vielleicht wäre es wirklich das beste, man würde für die FieldNotes eine eingene Datenbank-Datei (z.B. FieldNotes.sdf) erzeugen, in die dann alle Multi-DB's ihre FieldNotes eintragen können.

Hat von der Funktion her sicher den meisten Charme. Ich weiß allerdings nicht, ob SQL CE mit mehreren DBs gleichzeitig umgehen kann und ob das ressourcentechnisch vernünftig ist.

 

[Ging-Buh]

... braucht man wirklich die "field notes.html"?

Stört sie dich? Wieso stellst du immer gleich alles in Frage, was du selbst nicht brauchst?

Die html ist dazu da, dass man z.B. auch unterwegs schnell mal die eigenen FieldNotes betrachten kann. Ausserdem soll es ja Geocache-Plattformen geben, die die visits.txt nicht unterstützen. Da hat man dann die Möglichkeit, zu Hause die FieldNotes in einem etwas übersichtlicherem Format wie in der txt zu öffnen...

Ich teste in den nächsten Tagen auf Tour deine/eure Änderungen bezüglich der geocache_visits.txt aus und berichte ...

Wobei momentan bzgl. der geocache_visits.txt (noch?) nicht wirklich etwas geändert wurde, ausser dass es nun für jede Multi-DB eine eigende gibt und sich deshalb der Dateiname geändert hat. Die Funktion ist die gleiche geblieben.

 

[Ging-Buh]

Gelöscht wird nur bei DNF (bei Write Note und NM weiß ich's grad nicht). Found it bleibt definitiv stehen und kann editiert werden. Wenn das bei allen Logtypen so wäre, wäre die "einfache" Lösung eigentlich ganz OK. Der Field Note Dialog bei GC hat ja mittlerweile eine Bulk Delete-Funktion. Man könnte dann einfach die überschüssigen Notes weglöschen und hätte alle Infos in der jeweils letzten Note pro Cache und Typ.

Siehst du, man lernt nie aus. Ist mir noch gar nicht aufgefallen, dass der Text der letzten Found! stehenbleibt und man einfach weiterschreiben kann. Nach kurzem Suchen habe ich die entsprechende Funktion dann auch gleich im Quelltext gefunden.

Hat von der Funktion her sicher den meisten Charme. Ich weiß allerdings nicht, ob SQL CE mit mehreren DBs gleichzeitig umgehen kann und ob das ressourcentechnisch vernünftig ist.

Ich sehe keinen Grund, warum SQL CE unter WinMob nicht mit mehreren DB's gleichzeitig umgehen können sollte. Mit SQL CE auf dem PC (WinCachebox) geht dies definitiv ohne Probleme. Besondere Preformace- oder Resourcen- Probleme würde ich jetzt auch nicht erwarten. Es käme auf den Versuch an...

Der größte Nachteil dieser Variante (aus meiner Sicht) wäre eigentlich nur der leicht erhöhte Programmieraufwand...

 

[Timo TA93]

Stört sie dich? Wieso stellst du immer gleich alles in Frage, was du selbst nicht brauchst?

Nein Hubert, sie stört mich nicht. Nur wußte ich nicht welchem Zweck sie dient. Ist aber im Thread von Inder beantwortet worden die Frage.

Die html ist dazu da, dass man z.B. auch unterwegs schnell mal die eigenen FieldNotes betrachten kann. Ausserdem soll es ja Geocache-Plattformen geben, die die visits.txt nicht unterstützen. Da hat man dann die Möglichkeit, zu Hause die FieldNotes in einem etwas übersichtlicherem Format wie in der txt zu öffnen...

Ist mittlerweile klar.

Wobei momentan bzgl. der geocache_visits.txt (noch?) nicht wirklich etwas geändert wurde, ausser dass es nun für jede Multi-DB eine eigende gibt und sich deshalb der Dateiname geändert hat. Die Funktion ist die gleiche geblieben.

Trotzdem ist mit der CB569 (angezeigt wird 557) das lästige Umlauteproblem weg. Danke!

 

[Ging-Buh]

Zum Thema FieldNotes und MultiDB habe ich mir nochmal verstärkt Gedanken gemacht.

Ich bin jetzt der Meinung, dass das Erstellen, Verwalten und Speichern der FieldNotes jeweils in der SDF so bleiben soll, wie es jetzt ist. Ist ja gut so. Das einzige Problem besteht ja nur darin, dass beim Upload jede DB einzeln geöffnet werden muss um die FieldNotes zu übertragen, mit dem Problem, dass diese evtl. nicht in der richtigen Reihenfolge übertragen werden.

Man könnte nun einfach beim Übertragen der FieldNotes zu GC.com alle vorhandenen Datenbanken (SDF-Dateien) eine nach der anderen öffnen und die FieldNotes herauslesen. Diese können dann alle zusammen (sortiert nach Datum) in eine visits.txt geschrieben und zu GC.com übertragen werden. Würde eigentlich alle Probleme lösen. Oder?

Hab dazu auch schon einen Funktions- und Performance Test gemacht:

• Hab 4 SDF's erstellt (mit 1000, 1000, 84 und 30 Caches).
• In 3 SDF's insgesamt 16 FieldNotes "Found!" erzeugt
• CB mit der 4. geöffnet
• Während in CB die 4. geöffnet war nacheinander die anderen 3 SDF's geöffnet und mit einer SQL-Query die FieldNotes ausgelesen
• Hab damit eine Liste mit allen 16 FieldNotes bekommen, die jetzt in eine visits.txt geschrieben werden könnten
• Und das Beste an dem Ganzen ist, dass diese Abfrage der FieldNotes aus den 3 DB's insgesamt nur 1.6 Sekunden gedauert hat!

Das ganze wäre relativ leicht umzusetzen, da der Großteil des Codes weiter genutzt werden kann. Die Änderung die es möglich macht, mehrere SDF's gleichzeitig zu öffnen habe ich schon umgesetzt, der Rest wäre auch nicht mehr so schlimm...

Mit dieser Änderung wird übrigens dann auch der Fehler beseitigt, dass beim Wechsel der DB in CacheBox alte DB's nicht konvertiert werden und deshalb CB abstürtzt.

 

[Ging-Buh]

Kommando zurück!
Ich hatte gerade Kontakt zu hulkman und er hat ein triftiges Argument gegen diese Variante gebracht. Die visits.txt sollte ja nach jeder Eingabe einer FieldNote immer aktuell sein, nicht nur beim Upload. Viele Nutzer können/wollen den direkten Upload aus CB heraus nicht nutzen.
Wenn jedesmal bei der Eingabe einer FieldNote alle DB's abgefragt werden müssten... dann wären auch 2, 3 oder 4 Sekunden dann doch schon ein Problem. CB soll und muss schnell sein!

Es wird also doch auf eine eigene DB für die FieldNotes hinauslaufen... Werde mir mal Gedanken über den Aufwand machen....

 

[Harry1999]

Huhu,
eine Founds-DB wäre ein Traum.... immer alle gefundenen Caches mit allen wertvollen Info's vor Ort dabei... die Notizen, Solver, meine Waypoints, finals...
Grüße Harry1999

 

[Ging-Buh]

Huhu,
eine Founds-DB wäre ein Traum.... immer alle gefundenen Caches mit allen wertvollen Info's vor Ort dabei... die Notizen, Solver, meine Waypoints, finals...
Grüße Harry1999

Das ist aber ein ganz anderes Thema. Das hat mit der FieldNotes DB, von der hier die Rede ist nicht wirklich was zu tun.
Ich weiß jetzt nicht, ob du WinCB nutzt oder nutzen willst, aber damit wird in näherer Zukunft dieser Traum sicherlich wahr werden können.
Dazu aber später mehr. Jetzt müssen zuerst die FieldNotes richtig verwaltet werden und mal wieder eine neue stabile und (fast) fehlerfreie CacheBox Version erstellt werden...

 

[Der Gieger]

Feldauswahl - geht das?
Wenn ich mir das alles so durchlese kommt mir eine Idee:
Ist es sehr viel Programmieraufwand, wenn man dem Anwender die Möglichkeit gibt, die "Founds"-DB nach Belieben mit weiteren Datenbankfeldern zu ergänzen? In die "unveränderliche" Grundausstattung würde ich nur die Cachenummer und das Statusfeld (Found/DNF..) setzen, mehr nicht.

 

[Ging-Buh]

Feldauswahl - geht das?
Wenn ich mir das alles so durchlese kommt mir eine Idee:
Ist es sehr viel Programmieraufwand, wenn man dem Anwender die Möglichkeit gibt, die "Founds"-DB nach Belieben mit weiteren Datenbankfeldern zu ergänzen? In die "unveränderliche" Grundausstattung würde ich nur die Cachenummer und das Statusfeld (Found/DNF..) setzen, mehr nicht.

Wofür sollte das gut sein? Was möchtest du dann darin speichern?

 

[Der Gieger]

Feldauswahl - geht das?
Wenn ich mir das alles so durchlese kommt mir eine Idee:
Ist es sehr viel Programmieraufwand, wenn man dem Anwender die Möglichkeit gibt, die "Founds"-DB nach Belieben mit weiteren Datenbankfeldern zu ergänzen? In die "unveränderliche" Grundausstattung würde ich nur die Cachenummer und das Statusfeld (Found/DNF..) setzen, mehr nicht.

Wofür sollte das gut sein? Was möchtest du dann darin speichern?

Die Founds sollte für die "Zahlensammler" gut sein, gerade bei Multi-DB, damit die Zahl der exakten Funde festgehalten und ermittelt werden kann. Wer dann Sonderwünsche hat (seine Notizen, DNF's etc. seperat mit aufzubewahren) kann sich hier Felder einrichten. Die muß dann kein Anderer zwingend haben, der sie nicht braucht. Ich kann mir aber auch gut vorstellen, daß man das nur in der Win-CB einbaut.

 

[Ging-Buh]

Die Founds sollte für die "Zahlensammler" gut sein, gerade bei Multi-DB, damit die Zahl der exakten Funde festgehalten und ermittelt werden kann. Wer dann Sonderwünsche hat (seine Notizen, DNF's etc. seperat mit aufzubewahren) kann sich hier Felder einrichten. Die muß dann kein Anderer zwingend haben, der sie nicht braucht. Ich kann mir aber auch gut vorstellen, daß man das nur in der Win-CB einbaut.

Die exakte Zahl der Funde wird auch mit Multi-DB jetzt schon festgehalten. Der einzige momentan mögliche Weg, die Zahl der Funde durcheinander zu bringen, ist der dass du PQ's mit Funden importierst, die in CB nicht geloggt (mit FieldNote) wurden. Falls während dem Gpx Import eine Internet-Verbindung vorhanden ist und der Login korrekt eingegeben ist, wird die aktuelle Founds-Zahl nach dem Import auch hier von GC.com geladen.

Um in WinCB "alte" Daten von gefundenen Caches zu speichern würde ich einen anderen Weg gehen. Ich würde dafür keine neue DB oder Tabelle anlegen. Auch keine Benutzerdefinierten Felder in irgendwelchen DB's.
Warum die gefundenen Caches in WinCB nicht einfach in der DB lassen? Da sind alle Informationen drin.
Um die gefundenen von den nicht gefundenen zu trennen und beim Export nur die Caches zu exportieren, die noch gesucht werden müssen, können die gefundenen beim SDF-Export mit dem Filter einfach ausgeblendet werden.
Falls du die gefundenen in einer eingenden DB unterwegs dabei haben möchtest (Telefonjoker...), einfach im SDF-Export eine neue (Founds.sdf) erstellen, in die nur die gefundenen exportiert werden sollen.

Was hältst du davon?

 

[Ging-Buh]

Hab gerade eine neue Testversion (Rev. 594) erstellt.
Die FieldNotes-Tabelle ist jetzt in eine extra DB ausgelagert (user\fieldnotes.sdf). Damit wird jetzt trotz Multi-DB nur eine FieldNotes.html und eine geocache_visits.txt geschrieben. Zeitliches Durcheinander beim Loggen aus unterschiedlichen DB's sollte jetzt problemlos funktionieren. Das sonstige Handling der FieldNotes ist genau gleich gebliegen.

Hab außerdem die Reihenfolge der Einträge in der geocache_visits.txt geändert. Näheres hierzu hier:
http://www.geoclub.de/viewtopic.php?f=114&t=53057

Download:
http://dl.dropbox.com/u/20077085/cachebox_installer_594.CAB
Und wie immer beim ersten Einsatz solcher TESTVERSIONEN mit größeren Änderungen: Bitte vorher Daten sichern!!!

Eine Liste weiterer Änderungen sollte bald hier
http://www.geoclub.de/viewtopic.php?f=114&t=52820
erscheinen.

 

[Der Gieger]

Die Founds sollte für die "Zahlensammler" gut sein, gerade bei Multi-DB, damit die Zahl der exakten Funde festgehalten und ermittelt werden kann. Wer dann Sonderwünsche hat (seine Notizen, DNF's etc. seperat mit aufzubewahren) kann sich hier Felder einrichten. Die muß dann kein Anderer zwingend haben, der sie nicht braucht. Ich kann mir aber auch gut vorstellen, daß man das nur in der Win-CB einbaut.

Die exakte Zahl der Funde wird auch mit Multi-DB jetzt schon festgehalten. Der einzige momentan mögliche Weg, die Zahl der Funde durcheinander zu bringen, ist der dass du PQ's mit Funden importierst, die in CB nicht geloggt (mit FieldNote) wurden. Falls während dem Gpx Import eine Internet-Verbindung vorhanden ist und der Login korrekt eingegeben ist, wird die aktuelle Founds-Zahl nach dem Import auch hier von GC.com geladen.

Um in WinCB "alte" Daten von gefundenen Caches zu speichern würde ich einen anderen Weg gehen. Ich würde dafür keine neue DB oder Tabelle anlegen. Auch keine Benutzerdefinierten Felder in irgendwelchen DB's.
Warum die gefundenen Caches in WinCB nicht einfach in der DB lassen? Da sind alle Informationen drin.
Um die gefundenen von den nicht gefundenen zu trennen und beim Export nur die Caches zu exportieren, die noch gesucht werden müssen, können die gefundenen beim SDF-Export mit dem Filter einfach ausgeblendet werden.
Falls du die gefundenen in einer eingenden DB unterwegs dabei haben möchtest (Telefonjoker...), einfach im SDF-Export eine neue (Founds.sdf) erstellen, in die nur die gefundenen exportiert werden sollen.

Was hältst du davon?

Klingt gut, sehr gut sogar.