ACB: Pfad zur Datenbank

[klausundelke]

Ich hab auf meinem Galaxy SII ACB in
\mnt\sdcard\external_sd\cachebox
liegen.
Läuft soweit alles prima, nur die Datenbankauswahl bleibt immer leer.
Die aktuelle Datenbank aus der config wird verwendet, aber wenn ich in die
Auswahl gehe bleibt das Fenster leer. Wenn ich eine neue Db erzeuge
kommt die immer in
\mnt\sdcard\cachebox
Gibt's da noch eine Stelle wo der Pfad gespeichert ist?

 

[arbor95]

alle Datenbanken immer da \mnt\sdcard\cachebox (soviel ich weiss)

 

[Longri]

Vorerst!

Denn meine, für mich gesetzten, Aufgaben sind die Überarbeitung der Settings.

Insbesondere editierbarkeit aller Pfade und das bearbeiten der Masken für die Fieldnotes.

Gruß Andre

 

[GeoSilverio]

Ja, das wird ein "Problem" in Cachebox sein.
Ich kann es zwar nur vermuten, stelle es mir aber so vor:
In der config-Datei kann man den direkten Pfad zur Datenbankdatei hinterlegen, die genutzt werden soll. Ich vermute, dass die Routine, die nach DB3-Dateien sucht und diese dann beim Start in der Auswahl präsentiert, nicht auf diesen Pfad zugreift, sondern eben fix auf \mnt\sdcard\cachebox

Du kannst das ja mal in den Bugtracker eintragen auf http://www.team-cachebox.de
Rein Gefühlsmäßig sollte das keine riesige Sache in der Programmierung sein. Auf der anderen Seite ist natürlich die Frage, ob man nicht sowieso das external_sd mal durch kopieren der Karteninhalte auf den PC, dann formatieren der Karte und Rückspielen der Inhalte, wieder gerade bekommt.
In Cachebox lässt sich das vielleicht noch ändern, ich fürchte nur, dass es noch mehr Programme gibt, die einfach Voraussetzen, dass irgend etwas in dem Standardpfad abgelegt ist...

 

[Ging-Buh]

Vorerst!

Denn meine, für mich gesetzten, Aufgaben sind die Überarbeitung der Settings.

Insbesondere editierbarkeit aller Pfade und das bearbeiten der Masken für die Fieldnotes.

Gruß Andre

Hallo Andre,

ich hätte zum Thema Config auch noch was, worüber wir aus meiner Sicht zumindest mal diskutiert haben sollten.

Bei mir habe ich immer wieder das Problem (ca. jede Woche mind. 1x) dass die Config irgendwie zerstört ist und Cachebox mit Standardeinstellungen startet. Alle Einstellungen incl. AccessToken sind dann weg. Und so wie ich das hier sehe bin ich mit diesem Problem nicht alleine.

Ich denke schon lange darüber nach, die Config Einstellungen in eine CB zu verlegen. Die Config in der Datei hat den Nachteil, dass jedesmal wenn ein einzelner Wert geändert wird immer die gesamte Config geschrieben werden muss.

Außerdem gehören einige Config-Einstellungen aus meiner Sicht nicht in eine globale Config sondern zu den einzelnen Datenbanken.

Wir könnten also die globalen Config-Einstellungen in eine neue DB schreiben und alle Einstellungen, die zu einer DB gehören in genau diese DB. Technisch kein Problem, die entsprechende Tabelle in der DB und die Funktionen zum Zugriff sind sogar schon vorhanden. Die globale DB anzulegen wäre auch kein wirkliches Problem.

Der einzige Nachteil wäre nur der, dass diese Config in der DB nicht mehr mit einem Editor direkt geändert werden könnte. Da bräuchten wir dann eine entsprechende Möglichkeit entweder über ACB oder vielleicht über ein externes Programm...

 

[Longri]

Ich gehe gerne mit, wenn wir die Config in eine DB verlagern.

Was ich aber in der jetzigen Version gut finde, ist das Handling, für uns, einen neuen Eintrag zu erstellen.

Du weißt wie schwer ich mich mit DBs tue.

Und da ich die Einstellungen über den Settings Dialog editierbar machen möchte, bräuchten wir auch kein Editor. Und zur Not gibt es SQLITE viewer.

Gruß Andre


PS. @ Silverio. Damit ist eine Beschreibung hinfällig!

 

[GeoSilverio]

...Ich denke schon lange darüber nach, die Config Einstellungen in eine CB zu verlegen.

Ich denke du meinst DB, statt CB

Der einzige Nachteil wäre nur der, dass diese Config in der DB nicht mehr mit einem Editor direkt geändert werden könnte. Da bräuchten wir dann eine entsprechende Möglichkeit entweder über ACB oder vielleicht über ein externes Programm

Grundsätzlich ist das ein guter Ansatz.
Aber eben auch mit den genannten Nachteilen.
Es gibt ja so einen kleinen aber feinen Grundsatz: KIS ---> Keep It Simple!
Auf der anderen Seite ist die config definitiv mit mehreren Datenbanken überfordert und ohnehin ausgereizt.
Einstellungen zu einem Pfad, letztem Filter, letzte Sortierung etc., betreffen entweder immer nur die gewählte DB oder eben alles, Dazwischen gibt es nichts, es sei denn man macht für jede DB dann wieder eigene Sektionen oder sowas.

Der Nachteil einer DB-Lösung wiegt allerdings schwer. Man kommt nicht von außen dran!
Es müsste also eine elegante, flexible Lösung sein in CB, also die Möglichkeit eines kleinen Editors. Ob der dann separat laufen können muss oder in CB integriert, ist eben die Frage.

Edit, da Andre schon geschrieben hat:
Das in den Settings zu verankern ist sicher gut.
Man müsste mal alle bislang bestehenden config-Einträge durchgehen und daraufhin abklopfen, ob diese Einstellungen evtl. von außen, also ohne laufendes CB editierbar sein sollten/müssen. So kommt man sicher schnell dahinter, wo die Knackpunkte sind.

Evtl. könnte es ja auch einige wenige basale config-Einträge geben, die von außen ja leicht änderbar sind, der ganze Rest kommt in eine DB, wiederum mit globalen Einträgen und dann dynamischen Einträgen je DB.

 

[GeoSilverio]

PS. @ Silverio. Damit ist eine Beschreibung hinfällig!

Ja, warten wir erst mal ab...

 

[Ging-Buh]

Ich gehe gerne mit, wenn wir die Config in eine DB verlagern.

Was ich aber in der jetzigen Version gut finde, ist das Handling, für uns, einen neuen Eintrag zu erstellen.

Du weißt wie schwer ich mich mit DBs tue.

Und da ich die Einstellungen über den Settings Dialog editierbar machen möchte, bräuchten wir auch kein Editor. Und zur Not gibt es SQLITE viewer.

Gruß Andre

Hallo Andre,

wenn das ganze mal angelegt ist (und das ist es ja im Prinzip schon fast) dann brauchst du bei der Verwendung des ganzen keinerlei DB-Kenntnisse. Beim Anlegen eines neuen Config-Wertes muß dann an der DB-Struktur nichts geändert werden.

In der DB gibt es eine Tabelle [Config] mit nur 2 Spalten: [Key] und [Value].
Der [Key] ist der Schlüssel (vor dem "=") und der [Value] der Wert (nach dem "="). Im Prinzip genau wie in der Cachebox.config.

Der Zugriff auf das Ganze geschieht über die Methoden "ReadConfigString(String Key)", "ReadConfigLong(String Key)" der Database.java und ist in ACB sogar schon vorhanden...
Das Schreiben über "WriteConfigString(String Key, String Value)", "WriteConfigLong(String Key, String Value)"...
Wenn damit dann ein neuer Wert geschrieben werden soll, wird einfach eine neue Zeile in der [Config] Tabelle erstellt. Funktioniert nach Außen hin im Prinzip genauso wie aktuell die Config-Datei.

Ein Editor wäre auch nicht wahnsinnig aufwändig. Man könnte z.B. in die DB-Auswahl über das Menü einen Config-Editor starten. Diesen dann entweder für die globale Config oder für die lokale Config der aktuell gewählten DB. Der Editor müsste dann nichts anderes machen, als die 2 Spalten [Key] und [Value] in einer Tabelle darstellen und die Spalte [Value] änderbar machen...

Grundsätzlich wäre ich bei einer Umstellung sofort dabei.... Das dauernde Neuerstellen der Config nervt mich schon seit Monaten...

 

[Longri]

Na denn los. Wenn ich ein DAO für eine Hashmap<String,String> habe, baue ich einen Editor dafür, der auch ausserhalb von ACB läuft.