I'm developing a content provider which stores its data in an SQLite database. During development, I need to change the schema, or delete the database entirely and have it rebuilt (I'm not upgrading the database at this stage of development).
I found the database file, stored at /data/data//databases/app_db . When I pull it to my desktop machine, I can use SqliteSpy to see its content and all is well. However, when I delete it, it doesn't always get really deleted. Although I can't see the file in DDMS or ADB, my application still sees it.
I tried to make sure my application and service aren't up when I delete the file, but it doesn't seem to help. In about half the times I delete the file, I need to restart the emulator for it to have effect.
What could be preventing the file from being really deleted?
Itay.
I've seen this issue too when was writing unit tests for my ContentProviders. You need to make sure you've killed the process that hosts ContentProvider that uses that specific database file. And only than delete it.
Related
I have an Android app that writes data to a db. Initially, when we started, we stored the db in an app-specific folder (something like /storage/org.domain.app/db/db.sync and so on). Things worked with no issues. However, the issue was that this DB would get wiped out everytime we reinstall the app.
We therefore moved the DB to a different folder outside the app. (Now the path is something like /storage/data/db/db.sync). Now, if we reinstall the app, we still have the old DB entries. However, now reading and writing to the DB is a lot lot slower.
I am not sure if this slowness is because the amount of data has shot up. Since the data is now persistent across multiple reinstalls.
I suspect this could also be because the DB is now in a folder external to the app. To rule this out, I setup the DB in an app specific folder and intend to copy the entire DB from some previous tests (that contains lot more data - the amount of data which caused the DB access to slow down). However, I am unable to do so.
Some questions:
1. I am not able to actually access the folder where the DB is setup. The folder is created in Context.MODE_PRIVATE mode. Therefore, only the app itself can access it. I tried changing it to MODE.WORLD_READABLE. However, this is deprecated and throws an exception while using it. Is there a way to make this folder easily editable?
I also tried accessing the DB from Device file explorer in Android studio. I opened the existing DB (db.sync file) and just copy-pasted the large DB I already have. However, it looks like this method does not allow us to copy or even display more than 400 KB of information. The DB I have is around 60-70 MB. Hence this approach did not work either.
Is there a way I can edit the db.sync file?
Does DB being in a folder external to the app make it slower? Esp when there are too many entries. In my case, certain search operations happen via a local cache and happens in a giffy. However, we also need to log some stuff to the DB and that takes forever. I figured this out by adding timer logs in the code.
Anything else, I could do to identify if the DB path is causing the issue?
Thanks,
Anand
I am looking for a way to sync database and photos between devices trough Dropbox. The purpose is that several devices can add delete and update data and photos.
I thought about exporting the .db file but it would be difficult to update, I think it would rather overwrite the previous file. Maybe working with CSV is a good approach, because the app would be actually read and compare before updating its database and files.
The app will have something likea sync button or something that trigger sync.
I know that it would be correct to use an own SQL server, but I would rather avoid that.
Any ideas?
I'm trying to create some sort of backup & restore function in my app. Before that, I've been reading for a while to understand if it's possible to achieve, but I found out this question:
Sqlite DB Android Backup/Restore
The only other way I could see to do it, would be to read the actual contents of the DB and generate a file containing the SQL which which it can be restored from, this is obviously a more complex and doesn't offer any advantages to justify this complexity.
This answer, I think, is the best way to accomplish that; not explorting the .db file, but exporting queries.
You know; when you export a SQL data from mysql, you get a file which contains all the queries that creates the structure and queries that fill the structure with data.
That's what I'm trying to mimic; generate a file which contains sql queries from a .db file.
Do you guys think it's possible, I mean, is there any builtin method to achieve that?
Otherwise, if its too hard to handle, how do you manage to avoid what this user (https://stackoverflow.com/a/10842043/1943607) is talking about?
So, I disabled WAL with "PRAGMA journal_mode = DELETE" and then I was able to view the database in the browser and able to restore it on my test device fine.
That previous part, I can't understand it. Is this a configuration you set to sqlite?
Thanks
I haven't actually tried this with sqlite, but with mysql you could do things like create "dumps" of your database. Those dumps contained exactly what you describe: a set of queries that, when executed together, recreate the database, including the contents.
Judging from the "sqlite3" documentation found at http://www.sqlite.org/sqlite.html (especially the "Converting An Entire Database To An ASCII Text File" section), you can do the same for sqlite. Since you can execute shell commands from a java application (using Runtime.getRuntime().exec() methods), and you are the "owner" (Linux user id) of the database, you should be able to run this "sqlite3 .dump" command even on a non-rooted device. I have never seen an Android device without the sqlite3 tool installed, so the command should always be available.
Moreover, since dump file is just a text file, you should be able to prepend any PRAGMA's to it that are required for compatibility (like the one you quoted).
I haven't tested any of this, but just wanted to think with you on this interesting topic.
An sqlite database is just a file so you could copy the file but I think you may have problems with permissions in android preventing you from accessing the database.
A better solution IMO would be to sync your data to an external website.
Using a combination of a custom sync adapter and the account manager with a website or web service that has a RESTfull api to receive and send the synced data would be the most reliable approach.
http://developer.android.com/training/id-auth/identify.html is a great introduction to setting up the account manager.
And for a custom sync adapter this is a great starting point.
http://www.c99.org/2010/01/23/writing-an-android-sync-provider-part-1/
and http://www.c99.org/2010/01/23/writing-an-android-sync-provider-part-2/
And finally an explanation of how it all fits together
https://sites.google.com/site/andsamples/concept-of-syncadapter-androidcontentabstractthreadedsyncadapter
The above approach would enable a user to switch phones and retain data at the same time and the data would always be up to date (providing you sync at the appropriate times.
It seems like a lot of work as you will need to set up a web service but it is the BEST way to make sure data is kept safe and secure and can be restored and backed up at any point.
For a web service there are lots of options available to you including cloud services such as Google docs or writing your own website. Ruby on Rails is a great solution for developing your own site as you get a full RESTfull api out of the box and it;'s dead easy to secure/lock down a rails site to authorised users only with a couple of lines of code and with Heroku you can get free hosting.
As usual with Android development the simplest of requirements actually ends up being the most difficult to implement but where data safety is paramount then it's worth the effort to do it properly.
The question is too open to answer simply because the changes that may apply to the db file content are open and one can't guarantee a specific behavior .
On the positive side sqlite project is an open source and the format of the DB file is specified Here
After taking a look there, it seems very possible/not too complicated to parse any DB file looking for Data Only and write it/dump it to another functional db file.
I believe this is the fastest and cleanest solution to the issue in hand.
so to wrap up:
Copy DB file everytime you want to back it up.
When you want to restore create a new DB using Android APIs.
Parse the data from the backed up file and write them to the newly created DB.
P.S:
regarding how to use
PRAGMA journal_mode = DELETE
Simply use db.exec("PRAGMA journal_mode = DELETE"); when creating the DB
I am new to Android and Java. I am creating an Android application in which I will be collecting data and also importing data from server to Android.
I wish to store the data imported into SQLite tables. So I created two tables as per my requirement. This tables should be created when ever app is opened and should be cleaned when ever the app is CLOSED not switched. For this I am dropping the tables in onOpen(), it is working fine in Emulator. I am able to see the values in DDMS-Data.
Now I am trying to implement it on android mobile and I am looking at data folder in DDMS for the device. But I don't see any tables. The folder remains empty.
Sometimes its restricted to view table inside data folder for Device as manufacturer by default have not given permission to view it.But your tables do exist inside your data folder.
You can check by opening it inside your app if you want to confirm. You can definitely drop your tables and it will get cleaned when ever the app is closed don't worry about it. You have to root your device to get permission , which will take away your device warranty.
You cant check Database table from Device by ddms utility. cause it wont be listed there, but you can check data by applying a select query, wherever you want to debug.
Some devices needs to be 'rooted' in order to be able to access the data folder. You can read more about this process on wikipedia http://en.wikipedia.org/wiki/Rooting_%28Android_OS%29 However if you need it only to see your tables it's not recommended to do it.
I create only a table from code but inside still empty. I instead insert data by pull a file out and insert by SQLite Browser when run the emulator then, put it back to the data/data/package_name/file.db with this solution, after run the program I can see the list of information in Emulator. But moving the application on a real device, I cannot see any list of information on a real device. How should I do?
Because my application just provide the data to user, so user has no need to add or edit data to the database. In addition the data don't need to change very often. that's why I use SQLite Browser to insert data.
I know that there are some security constrain in (not-rooted) device. However, are there any suggestion about the solution.. How should I edit my code?
You can package your database in your res/assets/ folder and then copy it onto the /data/data/YOUR_APP_FOLDER/databases if the database does not exist (i.e., first install) or if it's older than the file in the assets folder (i.e., updated apk).
This post has a full working example: http://www.reigndesign.com/blog/using-your-own-sqlite-database-in-android-applications/