Falsche Database wird verwendet

[MikelKatzengreis]

Hallo,
ich habe eine kleine app, die auf eine sql database zugreift.
Ich konnte die auch auf einem Testgerät installieren.

Jetzt musste ich zwei Felder der Database ändern. Auf dem Testgerät habe ich die app deinstalliert und dann neu installiert. Blöder Weise greift die app immer wieder uf die alte Database zu. Alle versuche die alte DB auf dem Gerät u finden schlugen fehl. Auch die Überprüfung in ANdraoi Studio brchten keine Erkenntnisse.

Wo zum Teufel nimmt das Testgerät immer noch die alte DB her?

Habe zur Vorsicht die DB in den Ordener 7main7assets kopert. Auch kein Erfolg.

Hat jemand eine Idee? Würde gerne die APK so erstellen, dass die app auch die (richtige) Database erkennt.

Es grüßt Euch

Michael

 

[swa00]

Blöder Weise greift die app immer wieder uf die alte Database zu. ....Wo zum Teufel nimmt das Testgerät immer noch die alte DB her?

Hast du denn in der Manifest das Backup aktiviert ?

Alle versuche die alte DB auf dem Gerät u finden schlugen fehl. Auch die Überprüfung in ANdraoi Studio brchten keine Erkenntnisse.

Kannst du mit AS als Debug einsehen - ansonsten geht es nicht

 

[MikelKatzengreis]

Hi,
ja-im Manifest steht android:allowBackup="true"
Was meinst Du mit AS als Debug einsehen?
Wenn ich mir auf dem Zielgerät mittels des Device Explorers die Data/dat usw. ansehe steht dort nur eine Rumpfversion der Datenbank, nicht aber die, die im Ordner assets steht.

Werde jetzt erstmal try und error Verfahren anwenden und zwei Dinge tun:
Im Manifest Backup auf false stellen und zusätzlich eine neue Buildnummer vergeben.

Melde mich wenn das Ergebnis vorliegt

 

[swa00]

ja-im Manifest steht android:allowBackup="true"

Das ist der Grund - also ab auf "false"

Wenn ich mir auf dem Zielgerät mittels des Device Explorers die Data/dat usw. ansehe steht dort nur eine Rumpfversion der Datenbank, nicht aber die, die im Ordner assets steht.

Ich weis nicht woher du das hast , aber man kann keine DB in den Assets bearbeiten.
Du musst die schon vorher auf den cache/files Ordner zur Laufzeit verschieben/ kopieren .
Dafür bietet sich eine asnychrone Routine mit MD5 check an

Nur dann, wenn alle Indexe erstellt sind und nur readOnly, ist das Möglich - aber sehr sehr ugly.
Würde ich persönlich niemals tun.

 

[MikelKatzengreis]

@swa00 Hand vor Strine klatsche: AS = Android Studio
manchmal stehe ich mir selber im Weg

 

[swa00]

Alles Gut Nix passiert

 

[MikelKatzengreis]

@swa00
Hi, dass mit dem assets stammt aus einem Deiner Beiträge - vom 30.6.2023
Da muss isch wohl etwas falsche verstanden haben.
Den cache Ordner auf dem PC habe ich gelöscht.

Jetzt bleibt "nur" noch meine Frage wie und wann genau ich die Database in den cache Ordner kopiere.

 

[swa00]

Hi, dass mit dem assets stammt aus einem Deiner Beiträge - vom 30.6.2023

Welcher Beitrag ?
Ich finde keinen , wo ich geschrieben habe ,dass man eine DB in den Assets bearbeiten kann

Jetzt bleibt "nur" noch meine Frage wie und wann genau ich die Database in den cache Ordner kopiere.

Hier mal eine "Aldi" Copy Version


Ich würde aber mit getFilesDir arbeiten

///////////////////////

File filePath = new File(String.format("%s/weather/", context.getFilesDir()));
if (!filePath.exists()) filePath.mkdirs();
SQLiteDatabase db1 = this.getWritableDatabase();
db1.execSQL(CREATE_TABLE.....);
db1.close();

private void copyDatabase(Context context, String dbName) {
    File dbFile = context.getDatabasePath(dbName);
    if (!dbFile.exists()) {
        try {
            InputStream is = context.getAssets().open(dbName);
            OutputStream os = new FileOutputStream(dbFile);

            byte[] buffer = new byte[1024];
            while (is.read(buffer) > 0) {
                os.write(buffer);
            }

            os.flush();
            os.close();
            is.close();
        } catch (IOException e) {
            throw new RuntimeException("Error copying database from assets folder", e);
        }
    }

}

 

[MikelKatzengreis]

Hallo swa000,
jetzt hab ich es geschafft. Dank Deines Hinweises mit dem Code private void copyDatabase() und einigen Anpassungen in meiner MainActivity sowie dem databaseHelper klappt es nun. Jetzt habe ich auch verstanden was Du mit der Anmerkung "zur Laufzeit" gemeint hast.
Danke für Deine Hilfe

 

[MikelKatzengreis]

Hallo nochmal,
Ihr könnt mich ja schlagen, aber so ganz habe ich es noch nicht verstanden und auch nicht umgesetzt bekommen.

Mein Code:
public Databasehelper(@Nullable Context context) {
super(context, DATABASE_NAME, null, 1);
this.dbName = "ilmthf.db";
this.mcontext = context;
//this.dbPath = "/data/data/" + "com.example.ern2" + "/databases/";
//this.dbPath = Environment.getExternalStorageDirectory().getPath();
File filePath = new File(String.format("%s/weather/", context.getFilesDir()));
if (!filePath.exists()) filePath.mkdirs();
SQLiteDatabase dbName = this.getWritableDatabase();
}

Benutze ich den, so wie er da steht, funzt das auf dem Emulator. Auf realen Handy stürzt die app ab.

Ihr seht noch zwei auskommentierte Zeilen.
Die erste Zeile klappt auf dem realen Handy, aber nicht im Emulator.
Die zweite Zeile klappt auf dem Emulator, aber nicht auf dem realen Handy.
Letzterer Effekt eben auch mit dem obigen Code.

Jetzt weiß ich nicht mehr weiter, außer den hardcoded Pfad zu nutzen, obwohl ich weiß, daß das eigentlich falsch ist und bei Weitergabe der app auf anderen Handies evtl. Probleme bringt.

 

[swa00]

nochmal : getFilesDir nix mit enviorment

Und warum ist da mein snippet dabei ?

Und vermeide den Emulator. IMMER mit Adb und Device arbeiten

 

[OnkelHorst]

@MikelKatzengreis Hallo.

String databasePath = getContext().getDatabasePath("mydatabase.db").getAbsolutePath();
Und nicht anders.
Android erstellt in diesem Verzeichnis die Datenbank.
Automatisch. Sowohl Verzeichnis als auch Datenbank.
Und auch nur dorthin solltest du diese kopieren.
Nicht, wie gezeigt, ins Cache-Verzeichnis, das ist grober Unfug.

Deine Probleme können an mangelnden Zugriffsrechten liegen.
Im Konjunktiv, da ich deinen Code inklusive des Manifests nicht kenne.
Nur am Rande, da mir auch dein Kenntnisstand unbekannt ist, nur im Manifest reicht nicht, sondern auch im Code muss explizit die Erlaubnis angefordert werden.

Des weiteren, mir ist ebenfalls unbekannt, für welche Android-Version du codest, gab es gravierende Änderungen seitens Google.
Und mit gravierend meine ich wirklich gravierend.
WRITE_EXTERNAL_STORAGE und READ_EXTERNAL_STORAGE funktionieren ab 12(meine ich, bin mir unsicher, nicht darauf festnageln) nicht mehr.
Unter anderem.

Große Probleme treten bezüglich Zugriff auf Dateien mit Android 10 auf, falls möglich, minSdk = 30 (Android 11) oder höher setzen.
Aufgrund unterschiedlicher Androidversionen in Emulator und Gerät kannst du abweichende Resultate erzielen.
Fürs Grobe und weit ins Feine hinein genügt der Emulator, lass dir nichts erzählen.
Der richtige Spaß beginnt dann allerdings, wenn man auf verschiedenen Geräten testet.
Da braucht man gute Nerven, um alles anzupassen.

Das Kopieren der Datei läuft über
InputStream input = context.getAssets().open(DATABASE_NAME); // Datei aus Assets der Rest wie oben.

 

[swa00]

@OnkelHorst

Oh jee , oh jee .......

Nicht, wie gezeigt, ins Cache-Verzeichnis, das ist grober Unfug.

Hat keiner geschrieben - Wer lesen kann, - oder gar SourceCode versteht - ist klar im Vorteil.

File filePath = new File(String.format("%s/weather/", context.getFilesDir()));

(Post#8)

String databasePath = getContext().getDatabasePath("mydatabase.db").getAbsolutePath();
Und nicht anders.
Android erstellt in diesem Verzeichnis die Datenbank.

Falsch, tut es erst mal damit nicht -siehe API Doc - Das wurde auch eh nicht angefragt, benötigt er auch nicht , also unrelevant.

Und auch nur dorthin solltest du diese kopieren.
Nicht, wie gezeigt, ins Cache-Verzeichnis, das ist grober Unfug.

Nun, wenn es Unfug ist, dann würden wir uns freuen ,von Dir die entsprechende Richtlinien dazu zu erfahren, dass DB's nur in dieses Verzeichnis platziert werden dürfen.
P.s. Es wird auch nicht kopiert , sondern ein Block-Stream aus den Assets aufgebaut.

Große Probleme treten bezüglich Zugriff auf Dateien mit Android 10 auf, falls möglich, minSdk = 30 (Android 11) oder höher setzen.

Na das wäre auch mal recht neu - woher hast du das denn ... ?
Hinweis : Wir befinden uns hier im gleichen Paket-Environment. Da scheinst Du aber Einiges ordentlich durcheinander zu werfen.
Offensichtlich weist du auch nicht, was minSDK bedeutet

Deine Probleme können an mangelnden Zugriffsrechten liegen.

Auch hier wäre es für Dich zielführend gewesen, sich einmal vorher die API-Docs anzuschauen.

Nur am Rande, da mir auch dein Kenntnisstand unbekannt ist, nur im Manifest reicht nicht, sondern auch im Code muss explizit die Erlaubnis angefordert werden.

Für die hiesige Aufgabenstellung falsch und erst recht nicht notwendig.

WRITE_EXTERNAL_STORAGE und READ_EXTERNAL_STORAGE funktionieren ab 12(meine ich, bin mir unsicher, nicht darauf festnageln) nicht mehr.

Du hörst aber auch nicht auf, noch mehr Blödsinn für diese Aufgabenstellung zu erzählen ......

(meine ich, bin mir unsicher, nicht darauf festnageln) nicht mehr.

Und das scheint dein Hauptproblem zu sein -> Unwissen - aber "groben Unfug" testieren wollen.

Dein gesamter Beitrag wirkt wie aus dem Google - Imperium "zusammengeschustert" - ohne jeglichen Zusammenhang, Sinn - und Sachverstand - Hauptsache etwas schreiben.

Aber vllt. entwickelt man ja in deinem angegebenen Wohnort so ........ würde durchaus Sinn ergeben




Selten so einen unqualifizierten Beitrag gelesen .... Jeden Tag was Neues
Nun denn - Wir sind auf deine fundierten Antworten gespannt......

 

[OnkelHorst]

@swa00

context.getFilesDir() ist nicht das Cache-Verzecihnis, richtig, mein Fehler, trotzdem falsch.
DB-Dateien gehören ins DB-Verzeichnis. Wofür sonst ist es da?
Wieso erstellt Android sie automatisch in diesem Verzeichnis und nicht woanders?
Wie, bitte schön, willst du darauf zugreifen?
Zeigst du mir bitte ein funtkionierendes Beispiel, wie du eine DB-Datei außerhalb dieses Verzeichnisses öffnest und eine SQL-Abfrage durchführst?

Wenn ich eine DB-Datei anfrage, erstellt Android diese automatisch in dem DB-Verzeichnis, wieso lügst du?
Probier es doch selbst aus.
Selbstverständlich meinte ich nicht, dass "String databasePath = getContext().getDatabasePath("mydatabase.db").getAbsolutePath();" eine DB-Datei erstellt.
Das wird auch jeder außer dir so verstanden haben, wie ich es meine, nämlich, das Ermitteln des DB-Verzeihnisses.
Wie steht es um dein Leseverständnis wenn du mir schon vorwirfst, Code nicht lesen zu können?


"P.s. Es wird auch nicht kopiert , sondern ein Block-Stream aus den Assets aufgebaut."
Ui, ein Erbsenzähler.
Jeder außer dir versteht, was ich mit kopieren meine, weil, dass ist es, was man mit Streams - ob Block oder nicht - anängt, sie kopieren Bits vom Input- zum Output-Stream.
Zu dem Rest dieses Absatzes siehe oben, warum macht Android das wohl und wie öffnest du eine DB-Datei außerhalb desselben und führst eine SQL-Query durch?

"Na das wäre auch mal recht neu - woher hast du das denn ... ?"
Nur aus der Praxis, du bist nicht auf dem Laufenden, einfach mal informieren.
Und, mal testen.
Zufälligerweise habe ich einen kleinen 23000 Zeilen Dateiverwalter inklusive FTP/SFT/WebDav-Zugriff geschrieben.
Dabei traten diese Probleme auf.
Nimm zB "/sdcard/tollerOrdner/DateiA", greif darauf mal zu, wenn du TargetSDK >= 33 hast.
Und SDK 29 ist dabei ein Spezialfall.
Von Android 9 auf 10 führte Google etwas neues ein mit dem Resultat, dass vieles mit Android 10 (SDK 29) zu Problemen führte.
Einfach testen und staunen.
Wieso willst du mich hier unbedingt als Idioten hinstellen?

"Auch hier wäre es zielführend gewesen, sich einmal vorher die API-Docs anzuschauen."
Ja, solltest du, stimmt.
ich verweise auf Zugriffsrechte, da der Fadenersteller in seinem Codebeispiel versucht, auf das FS zuzugreifen.
Dafür benötigt man Zugriffsrechte, oder?
Und ich war so frei, ihn auf die weiteren Probleme dieser Thematik hinzuweisen.
Mir war nicht bewusst, dass ich dich hätte vorher um Erlaubnis fragen sollen, tut mir leid, stand nicht in den API-Docs.

"Du hörst aber auch nicht auf, noch mehr Blödsinn für diese Aufgabenstellung zu erzählen"
Ja, immer schön beleidigen, klar.
Ändert aber nichts an dem Fakt, dass WRITE_EXTERNAL_STORAGE und READ_EXTERNAL_STORAGE ignoriert werden.
Das wusstest du aber bestimmt, oder, als großer Student der API-Docs.


Glashaus und Steine...

 

[swa00]

Dein letzter Beitrag zeigt leider

Du hast m.E. die gesamte Aufgabenstellung nicht verstanden.
-> Und dazu dann noch alles als "groben Unfug" bezeichnet.

Du wirfst eindeutig absolut unterschiedliche Themengebiete durcheinander. Jetzt wird auch Einiges klar

Ein "grober Unfug" löst unweigerlich eine Gegenwehr aus - So wie man in den Wald hineinschreit , so kommt es zurück.


Vor Allem :
Warum du dann - trotz erfolgreichem Ausgang und funktionierender Lösung ( siehe Post#9 ) nach ca. einem Monat , dennoch das Ganze als "groben Unfug" bezeichnest, ist schon sehr sehr seltsam

Spätestens dann hätte ich mir persönlich nochmal den Thread an Deiner Stelle durchgelesen, bevor man lospulvert.


Nochmal zum Verständnis:

Er möchte aus den Assets eine vorhandene Datenbank in den Envoirment DatenPfad bei der Installation des Pakets
synchronisieren , damit er sie dort bearbeiten kann - in den Assets ist das nicht möglich
(Siehe Post #4 ff)
Außerdem möchte er sicherstellen, das Änderungen bei einer erneuten Installation/Update nicht überschrieben werden
Siehe dazu Post#1 (Backup-Flag)
(Er befindet sich daher abgekapselt in seiner Paket-Blase)

Das wird auch jeder außer dir so verstanden haben, wie ich es meine, nämlich, das Ermitteln des DB-Verzeihnisses.

Dann solltest du das auch so schreiben und nicht nur denken

Android erstellt in diesem Verzeichnis die Datenbank.

Dort steht "erstellt" die Datenbank - und das ist falsch - eindeutig , daran ist nichts zu rütteln

Dafür benötigt man Zugriffsrechte, oder?

Nein , denn - wie oben bereits erwähnt , befinden wir uns im gleichen Paket-Environment.

Wie, bitte schön, willst du darauf zugreifen?
Zeigst du mir bitte ein funtkionierendes Beispiel, wie du eine DB-Datei außerhalb dieses Verzeichnisses öffnest und eine SQL-Abfrage durchführst?

Gerne:

Alle unsere DB's befinden sich in meheren unterschiedlichen lokalen Verzeichnisen, welche für die jeweilige Funktion Sinn machen . Und das OHNE Permissions und API check!

Wir selektieren damit seit Jahren erfolgreich das, was beim Cache-Löschen oder beim Daten-löschen durch den Nutzer geschieht. /dynamisch/statisch/permanent)
Dies wäre mit deiner "Annahme" schon mal leider gar nicht möglich.

Und wenn ich es grob Überblicke : Es werden derzeit um die ~50 Apps auf dem Markt sein.

Es gibt hier überhaupt keine Vorgaben wohin und wie , und es werden keinerlei Berechtigungen benötigt.
Jeder Entwickler entscheidet Art, Form und Ziel für sich selbst.

Und weil du es dir gewünscht hast - hier das Beispiel ohne jegliche Permissons in einem x beliebigen Pfad deines Paketes:

 public CitiesDB(Context context, String dbfilename)
    {
        super(context, dbfilename, null, DATABASE_VERSION);

        try
        {
            File filePath = new File(String.format("%s/onkel/", context.getFilesDir()));
            if (!filePath.exists()) filePath.mkdirs();
            SQLiteDatabase db1 = this.getWritableDatabase();
            db1.execSQL(CREATE_TABLE_ONKELHORST);

            db1.close();

        }  catch (Exception jj){}
    }

Call ( Bsp )

 mCitiesDatabase         = new CitiesDB      (mContext, mContext.getFilesDir() + "/onkel/horst"+CORE.d().DB_VERSION+".db");

Die Queries wie gewohnt.
Wenn Du dazu noch ein Beispiel benötigst : Melden

Nimm zB "/sdcard/tollerOrdner/DateiA", greif darauf mal zu, wenn du TargetSDK >= 33 hast.
Und SDK 29 ist dabei ein Spezialfall.

Nochmal zu deinem Verständnis .....
Der TE möchte das für sein Vorhaben gar nicht tun.
Dem TE ist API Level dabei gänzlich Schnuppe. Und das zurecht.

ich verweise auf Zugriffsrechte, da der Fadenersteller in seinem Codebeispiel versucht, auf das FS zuzugreifen.
Dafür benötigt man Zugriffsrechte, oder?

Nein , siehe oben - will er nicht , benötigt er nicht .... wie kommst du immer wieder darauf ?


Nichts mit Glashaus, sondern du solltest selbst schlichtweg bei der Aufgabenstellung bleiben , die der TE in den Raum wirft.
Und vor allem nicht Beiträge und Personen angreifen ..... Das kann man auch freundlicher formulieren, wenn man sich unsicher ist.

Ändert aber nichts an dem Fakt, dass WRITE_EXTERNAL_STORAGE und READ_EXTERNAL_STORAGE ignoriert werden.
Das wusstest du aber bestimmt, oder, als großer Student der API-Docs.

Nein, sie werden je nach api/ sdk einbindung und Zielplattform natürlich nicht ignoriert und sind ab api 30 als deprecated deklariert.

Aber bereits oben haben wir schon festgestellt, daß du die Bedeutung von minSdk noch nicht so ganz inne hast.

Ein gänzlich anderes Thema und Technik ...

 

[OnkelHorst]

Mein ".. erstellt eine DB-Datei .." bezog sich auf getWritableDatabase(), das gleiche gilt für getReadableDatabase().
Dein Beispiel ist falsch.
Die Methode getWritableDatabase() erstellt oder öffnet eine Datenbankdatei im Standardverzeichnis für Datenbanken der App.
Bei jedem, auch bei dir.
Und wenn du das angeblich auf tausend Apps durchexerzierst, die Methode erstellt immer im Standardverzeichnis für Datenbanken der App die DB.
Dieses Standardverzeichnis ermittelt man mittels "String databasePath = getContext().getDatabasePath("mydatabase.db").getAbsolutePath()".
Wie oft willst du mir das jetzt noch vorwerfen?

Dein Beispiel greift auf das DB-Verzeichnis zu.
Wie oft noch?
Zeige mir, wie du auf /egalwo/meine.db zugreifst und eine Query durchführst.
Nochmal:
Dein Code greift auf den Standardpfad für DB-Files zu.
Ich habe, obwohl nicht nötig, deinen Code bei ChatGPT mit der Frage nach der Datei(Name und SPEICHERORT) eingegeben.
Antwort ChatGPT:
>>Der tatsächliche Pfad der Datenbankdatei sieht in etwa so aus:
/data/data/<dein_paket_name>/databases/<dbfilename> <<
Also wieder der Android-Standard-Pfaf für Datenbanken.
Und? Mich wieder beleidigen?

Der Fadeneröffner schrieb "Jetzt musste ich zwei Felder der Database ändern".
Zwei Felder mittels einer Query, vermute ich? Oder wie interpretierst du das?
Und das funktioniert außerhalb des Standardordners nicht.
Beweise es mit.

"Und vor allem nicht Beiträge und Personen angreifen "
Ich habe keine Person angegriffen, du hast damit begonnen, nicht ich.
Lies meinen Post Nummer 1 und deine Replik darauf, wer greift hier wen an?

"Nein, sie werden je nach api/ sdk einbindung und Zielplattform nicht ignoriert und sind ab api 30 als deprecated deklariert."
Das meinte ich. Und sie werden ab 33(Android 13) ignoriert. Schau nach, mach dich schlau.
Und doch, du musst jetzt stark sein, ich weiss, was minSDK bedeutet. Vielleicht solltest du das nochmal nachschlagen?

"Der TE möchte nicht auf externe Files zugreifen"
Ich habe dir erklärt, wieso ich das Thema aufgriff.
Musst du nicht wiederholt drauf herumreiten, einfach akzeptieren oder tolerieren.

Das mit dem Verzeichnis von dir ist und bleibt grober Unfug, da
a) funktioniert nicht
b) von Mamma Google nicht erwünscht
Ganz am Rande, neben API-Docs gibt es auch noch Best Practices und andere Vorgaben seitens Google.

Ich erkläre es dir gerne nochmal, nur zu, allerdings nicht mehr heute, da Wochenende und so.
Du kannst ja ein bisschen in der API-Doku schmökern...

Nachtrag:
Dein Beispiel ist der größte Humbug überhaupt, das ergibt gar kein Sinn, du erstellst da eine Var filePath, die du danach gar nicht benutzt.
Augenwischerei.

 

[swa00]

Das mit dem Verzeichnis von dir ist und bleibt grober Unfug, da
a) funktioniert nicht

Und an dieser Stelle müssen wir feststellen , dass es absolut keinen Sinn machte , sich die Mühe zu geben .

Alleine a) zeigt , dass du einen mehrfach eingesetzten Snipped nicht einmal eingebunden, und compliert hast und wie gedruckt flunkerst.... Das war eigentlich schon zu erwarten - Wenig Kennnisse

Ich erkläre es dir gerne nochmal, nur zu, allerdings nicht mehr heute, da Wochenende und so.

Bitte nicht
Der erster Beitrag von Dir - und die Nachfolgenden , sind es nicht Wert .....
Ich bin auch hier raus .....

 

[OnkelHorst]

@swa00 Antworte doch.
Dein Beispiel ist Müll, es wird im Android-Standardverzeichnis für DBs eine Datei erstellt.
Du kannst keine Fehler eingestehen.

 

[swa00]

Antworte doch.

Das letzte mal , denn ich habe bereits angekündigt , dass ich mich nicht weiter mit dir beschäftigen werde und meinen Hauptberuf erklären muss ....

es wird im Android-Standardverzeichnis für DBs eine Datei erstellt.

Du hast das Thema in diesem Thread immer noch nicht erfasst und beginnst Grundsatzdiskussionen ,
die den TE nicht interessieren -

Du kannst dazu gerne einen separaten Thread aufmachen um der Welt deine Kenntnisse mitzuteilen.
Deshalb bin ich hier auch raus ....

Sau dämlich nur für Dich - das dein "Unfug" und deine angeblich nicht laufenden Beispiele hier in diesem Thread zur Lösung beigetragen haben .

Das sollte Dir zu denken geben......

 

[OnkelHorst]

Dein Beispiel funktioniert nicht wie intendiert.
Aufgabe war: zeige mir ein Beispiel, wie ich in einem beliebigen Verzeichnis eine SQL-Datenbank-Datei erstelle und darin eine Query druchführe.
Was zeigst du mir?
Code, der ein unbenutztes File-Objekt erstellt und auf das Standard-DB-Verzeichnis von Android zugreift.
SQLiteDatabase db1 = this.getWritableDatabase(); greift auf das Standard-DB-Verzeichnis von Android zu.
Wie oft noch? Ja?

Der Fadenersteller hat nicht gesagt, dass er das gewünschte Ergebnis erzielt hat, er hat schlicht nicht mehr geantwortet.
Weil dein Beispiel grober Unfug ist.

So, nun genieß dein Wochenende, damit du am Montag wieder voll da bist in deinem "Hauptberuf"...