How can I swap out the underlying SQLite DB?

[Zac Tolley]

I have an android application that relies on a sqlite database, and use OrmLite to access my DB.

Instead of OrmLite creating the tables I rely on downloading the database from a central server as the user will often want to "sync" things. Currently I don't have the fancy sync code written so the app replaces the db. The steps are:

1 Download the latest SQLite db file from the server, as a zip 2 Expand the file to produce a database.sqlite file in a temporary folder 3 Deletes the contents of a data folder, which contains the live database.sqlite file 4 Move the database.sqlite file from the temporary folder to the data folder.

The problem is that the new database file seems to get ignored and DAO queries I run return old data. The only way to show data from the new version of the DB is to restart the application. 

To test things I created a table with a timestamp that records when the database was generated, each time you request a new copy of the sqlite db from the server this is updated. I have a fragment that displays this time so you know how fresh your data is. In the fragments onResume method I make a call to the DAO to get the timestamp and put value on screen. I've stepped through this and I see the call to the DAO but the value that comes back is from the old, now deleted, db. Restart the app and the correct value is shown.

So my question is, if I replace the underlying sqlite db file that stores my database, how can I tell ormlite to pick it up or refresh the connection or whatever it has to do???

I tried calling clearObjectCache on the DAO, made no difference.

[Christine]

It should work if you download the new database from the server before you open the existing database, like when your app starts. 

[Vlad]

We use exactly same approach and it works. Make sure:

1. Close DB connection before replacing file
2. Replace file
3. Flush cached Dao objects
4. Re-open connections

Closing database:

In class which extends OrmLiteSqliteOpenHelper we created new method destroy() which removes all instances  - destroys singleton. After the file is replaced, we initialize databases again. In general this approach works flawlessly and we have not hit any issues.

Vlad

Dne pondělí 29. června 2015 16:02:18 UTC+2 Christine napsal(a):