SQLite DB mitliefern, bei Update nur bestimme Werte überschreiben

Hallo liebe Developer,

ich arbeite zurzeit an meiner ersten App. Es handelt sich um eine Art Quiz mit speziellem Modus (also nicht einfach Frage und 4 Antwort-Möglichkeiten ).
Die Fragen speichere ich in einer SQLite-Datenbank und liefere sie im assets-Ordner mit. Diese wird dann in das App-Verzeichnis kopiert, sofern noch nicht geschehen, wobei ich mich an diesem Tutorial orientiert habe.
Da ich jetzt so gut wie alles fertig habe, muss ich mich nun zum Schluss erneut um die DB kümmern. Mein Problem sieht folgendermaßen aus:
Bisher habe ich es einfach so gemacht, dass in einem Spiel verhindert wird, dass eine Frage mehrfach vorkommt. Beim nächsten Spiel kann es dann aber durchaus vorkommen, dass eine Frage nochmal drankommt, denn ich wähle sie einfach random aus. Ich glaube aber nun, dass es besser ist, wenn eine Frage nie mehr dran kommt, falls sie schon einmal gestellt wurde (solange bis alle Fragen durch sind ).
Um dies zu schaffen habe ich drei Ansätze. Entweder ich füge noch eine Spalte ein, in der vermerkt wird, ob die Frage schon dran war. Oder ich mache eine neue Tabelle, wo nur diese Information gespeichert wird... oder eine ganze neue Datenbank.
Vor allem letzteres mag sich absurd anhören, aber das Problem ist ja, dass ich die Fragen bei Updates auch erweitern oder Rechtschreibfehler usw. korrigieren möchte. Das wäre kein Problem, wenn ich die Zusatzinformation nicht benötigen würde, denn dann würde ich einfach im Falle einer neueren DB-Version die Datenbank überschreiben.
Aber jetzt sind da ja auch noch Informationen drinnen, die von User zu User unterschiedlich sind und die dürfen eben nicht überschrieben würden.
Für mich am leichtesten wäre deshalb die dritte Variante mit der eigenen Datenbank, die aber ziemlich unschön und ineffizient ist wie ich vermute.

Was würdet ihr vorschlagen?
Ich hoffe ihr versteht mein Problem.

Danke schonmal.
Gruß ;)
Alex

Etwa 15 Spalten. Und die Anzahl der Datensätze (also der Fragen-/Antworteneinheiten) wird anfangs 200 sein, ich möchte es aber schon auf 1000 steigern, sofern meine kreative Ader mitspielt, d.h. nach und nach immer ca. 200 weitere einfügen.
Preferences mit 200 - 1000 Werten, läuft das noch einigermaßen effizient?

— geändert am 14.08.2012, 15:20:41

@Ansgar: Ja, genau, das hatte ich auch in der engeren Auswahl.
Fand es halt nur etwas doof, extra für die kleine Tabelle dann noch eine Datenbank anzulegen.
Oder doch die Preferences-Variante von Harald?
Also wenn ihr meint, dass eine zweite Datenbank doch kein allzu großes Manko ist, würde ich es wohl so machen?

Ok danke, dann probiere ich das mal so.

Nur wens interessiert, habe es jetzt nach dem Urlaub so gemacht wie beschrieben und es klappt wie gewünscht. Danke! ;)

Hallo,

ich habe ein Problem mit meiner Datenbank.
Ich habe vor zwei Wochen die erste Version meiner App veröffentlicht. Die Datenbank wurde wie oben besprochen eingebaut. Kurz: In einer Datenbank, die in assets mitgeliefert wird, stehen die Fragen, in einer weiteren ob die jeweilige Frage schon dran war oder nicht. Beim ersten Mal wird die Fragendatenbank aus assets rauskopiert und die andere Datenbank auch angelegt. Es funktioniert alles wie es soll.
Beim Upgrade sollte einfach die neue Version erkannt werden (durch Erhöhung der db-Versionen in den Databasehelpern) und die neue db über die alte kopiert werden.
Nun habe ich die Datenbank erweitert und wollte ein Update veröffentlichen. Doch beim Testen ergaben sich verschiedene Probleme.
Ich habe zunächst bei mir (SGSII, 4.0.4) die neue signierte APK installiert. Wenn ich nun die eigentliche GameActivity starte, aus der die DatabaseHelpers instanziiert und die Verbindungen zu den Datenbanken erstellt werden, wird die onUpgrade gar nicht aufgerufen. Ich habe im Konstruktor korrekt 2 als Version übergeben, die alte Version ist 1. Per Log habe ich mir die Datenbankversion ausgeben lassen... und sie ist nach dem Update 2 - in die onUpgrade ging er aber wie gesagt nie rein. Ergebnis ist also, dass bei mir einfach die alte Datenbank bestehen bleibt (wenn man die Daten löscht und dann Clues startet, sind die neuen Fragen also mit dabei, da die Datenbank dann ja erst neu erstellt wird).
Okay, als nächstes habe ich die signierte APK auf dem Handy meines Bruders (SG Ace, 2.3.6) ausgeführt. Wenn ich hier das gerade Beschriebene tue, wird "die Anwendung unerwartet beendet". Der Log sagt mir, dass hierbei die onUpgrade ausgeführt wird, dabei aber die Datenbank wohl unbrauchbar wird:
Komisch ist auch, dass New database version auf 1 steht. Ich lasse das am Ende der onUpgrade ausgeben und es sollte demnach doch eigentlich 2 sein.

Außerdem ist mir noch aufgefallen, dass bei mir bei der aktuellen funktionsfähigen Version im Log erscheint:
Allerdings kann das irgendwie nicht sein, denn die Fragen werden ja sofort danach problemlos ausgelesen und angezeigt und beim Ace meines Bruders ist diese Meldung auch nicht aufgetreten. Also keine Ahnung, ob das vielleicht was mit dem Upgrade-Problem zu tun hat.

Ich weiß echt nicht, woran es liegt, habe schon überall nach Lösungen gesucht, aber nichts gefunden. Deshalb hoffe ich, dass ihr mir helfen könnt.
Bei Bedarf kann ich auch den betreffenden Code posten.

MfG ;)
Alex

Hab das Problem jetzt anders beseitigt. Und zwar nutze ich die onUpgrade einfach gar nicht mehr, sondern überprüfe selbst, ob die mitgelieferte Datenbank neuer ist. Falls ja, wird sie wie beim ersten Mal kopiert. So funktioniert es jetzt endlich richtig.
Warum der "normale" Weg solche Probleme bereitet, habe ich aber immer noch nicht herausgefunden. Naja, Hauptsache, es geht jetzt.

Danke für Deine Antwort! Also die user_version der db selbst stand auf 0. Bei meinem Bruder wurde sie ja auch aufgerufen. Allerdings war die db danach kaputt, wahrscheinlich weil - wie du sagst - die Methode nicht zum Austauschen der ganzen db gedacht ist.
Die zweite hingegen erzeuge und erweitere ich ja programmatisch und hier funktioniert es.
Das einzige Komische ist das unterschiedliche Verhalten meines Handys und das meines Bruders. Aber so ein bisschen Mystery ist ja heute ganz passend.

Beide hatten 0, ich habe daran nichts verändert. Die onCreate() ist leer. Das Kopieren wird in einer eigenen Methode durchgeführt (createDB()), die ich selbst aufrufe.
Die user_version 0 in meiner vorgefertigten Datenbank dürfte aber doch eigentlich gar keine Auswirkungen haben, denn sie befindet sich ja zunächst erst in assets. Die ausschlaggebende user_version übergebe ich doch über den Konstruktor des DBHelpers?

Ich habe mich im Wesentlichen an dieses Tutorial gehalten. Nur openDatabase habe ich nicht, dafür nutze ich einfach getReadableDatabase, nachdem kopiert wurde.
Glücklicherweise läuft es jetzt ja auch wieder.

Ja, aber wie gesagt, ich verwende nicht das openDatabase() wie er, sondern ganz normal getReadableDatabase().
Sry dass ich dich damit so nerve. xD

@Robokopp: Jo, es ist schon ziemlich anstrengend, sich die Fragen auszudenken. Habe nun aber schon über 200, siehe dieser Thread. Falls Du echt noch was hast, schreibe am besten dort, ich glaube, das hier ist der falsche Thread dafür.
@Harald:
Wie gesagt läuft das ganze kopieren jetzt, egal ob beim ersten Mal oder beim Überschreiben in einer Methode ab, die ich selbst aufrufe. Die onCreate und onUpgrade sind jetzt beide leer. Also wird da ja eigentlich auch nichts mehr gemacht, wenn ich bzw. meine create-Methode dann getReadableDatabase() aufrufen. So funktioniert es nun auch.
Du meinst wahrscheinlich das Problem, das ich hatte, als ich die Kopierarbeit in der onUpgrade verrichtet hatte?
Ja, da war wohl wirklich das, was Du erläutert hast, der Grund. Vielleicht erklärt das auch den Unterschied vom Handy meines Bruders zu meinem. Denn er hat ein Ace, ich ein S2. Und so wirkte sich die Race-Condition auf beiden Modellen unterschiedlich aus, da mein S2 halt einfach schneller ist. Das könnte sein, oder?