So I have an application on the market place. It's been running fine for several months. I've updated it twice with small bug fixes and made no change to the database what so ever.
Some of my users are getting the following error:
android.util.Log$TerribleFailure: Can t downgrade read-only database from version 2 to 1: /data/data/myapp/databases/MyAppDB
at android.util.Log.wtf(Log.java:275)
at android.util.Log.wtf(Log.java:254)
at android.database.sqlite.SQLiteOpenHelper.getWritableDatabase(SQLiteOpenHelper.java:129)
As I mentioned, there has been no change to the database if any of the updates. It obviously crashes when the getWriteableDatabase method is called. I'm stumped as to why this error is occurring.
My best guess is that the user's phone has no more space left and thus a writable database can't be openend and thus crashes the app.
Any ideas?
A sqlite database has a version number. The version number is set when you open the database.
For example, if you use SQLiteOpenHelper, the constructor has int version parameter.
The error you get happened because on the user's device there is an old database with version=2 set, but on your program update you are trying to open that old database requesting version=1. That's not allowed.
Just set the version on the updated program to 2 or more.
Related
I'm just toying around with my schema and I can't get my app to load at all since I changed the schema/Entity class.
I have deleted the app on my testing devic, cleared the caches on AndroidStudio, and rebooted my machine but the error persists. All I did was change the default values of one of my Entity data classes for my Room database.
How do I force AndroidStudio to forget about the old table schema/Entity class without incrementing the version number and providing a migration path?
Error:
java.lang.IllegalStateException: Room cannot verify the data integrity. Looks like you've changed schema but forgot to update the version number. You can simply fix this by increasing the version number.
Android Studio doesn't save the database schema information, your app does. So you can clear the app data on your test device and will fix the problem without incrementing your version number.
However without clearing the app data, you can use RoomDatabase.Builder.fallbackToDestructiveMigration() along with incrementing the version number to avoid implementing migration logic if you're happy to lose the contents of the previous database.
You can try setting android:allowBackup to false in the manifest file.
I have published my android app in google play store it works fine and perfect(my app first will go and create a sqlite DB using SQLiteOpenHelper class then the index.html page will be displayed) then i noticed that users with android version 2.3.6 have error when they install the app i solved the problem without changing or adding to the structure of the DB then after publishing the new version of my app without changing the version of the database my app will not show the index.html and i think it will keep trying creating the database and the user will just see the loading message only.
So do i have every time to change the database number even if i did not make any changes to my database structure to be published to google play store.
No, you only change the database version number to a higher version ONLY if you change the structure of the database or decide to automatically add data.
For example, you can start with version 1 with a database that contains only one table: let's call it User, and the table has a column called Username. You run the query to create the table on your onCreate method. Then you release the app.
Then you decide to add more features to the app, and implement a version of the app that did not require any database changes at all. Your db version stays 1.
Then on your next app version, you decide to add a column to the User table. So what you do, is increment the db version to 2, and then run the alter table statement on your onUpgrade method. Then you release the app.
I believe your issue lies somewhere else. Check your database data integrity and that it fits your app's model.
I have a database that I built in SQLite browser, and it works fine. I launched an app with a prebuilt database and now I want to add more tables and data to that database.
I can get the app to launch the onUpgrade() method of the SQLiteOpenHelper. But the problem is, it's doing that EVERY time I use the helper.
I have it localized to, only on app launch, separating the upgrade command from the helper I used to retrieve data, but this is still a problem.
I have figured it out though, as I have been using the same database on my computer (the one that I'm editing) since version 1. So, whenever it writes the newer database onto the SD card it's showing version 1 even though I should be up to version 4 by now.
So, my question is, how can I manually edit the database version of the original database so that when it updates it isn't writing the old version number over the new one?
To manually update the version to 4 you execute the following SQL statement:
PRAGMA user_version = 4
Another way to change the version of your Sqlite Database. You can use DB Browser for SQLite:
Open the database file with "DB Browser for SQLite".
Change the "User Version" number to whatever number you want
Click the "Save" button
You can also set it via the setVersion SqlLiteDatabase method.
Source: http://developer.android.com/reference/android/database/sqlite/SQLiteDatabase.html#setVersion(int)
I have been testing my app which uses the dbadapter from Reto Meir's earthquake example. Everything was going ok for several days but when debugging with the app on the device today I got the 'no such table' error. I changed the name of the database and all runs well again. This doesn't give me much confidence regarding potential other users.
Since it seems impossible to see the database on the phone, by design I suppose, I can't see how to find out what caused the problem and take steps to avoid it. The database appears to open ok at the start of the program but errors when handling a select query. Just changing the name of the table doesn't fix it, it has to be a new database name.
As the change of name allows it to run ok I can't see that the code is wrong. I wonder if the data becomes corrupted.
I've also found that after successfully inserting a row, then later getting a cursor to allitems sometimes produces a -1 error against a get for one of the column names. How can a column name drop out of the columns index?
I've googled this type of problem and whilst there are a lot of folks with the problem and a lot of replies I can't find anything which informs on the underlying reason for these problems - which is what I am after.
I was having the same problem with this. I was changing the version number, uninstalling application etc... in the end it was due to me not submitting the transaction of the sql call. It might be worth checking out the answer in the following for some clarity - https://stackoverflow.com/a/13568419/1634369
The database is available on the phone and if you can 'adb shell' to the phone, you can also use sqlite3 command line shell to connect, examine, query and modify your database. It's pretty much the same functionality as you'd get with oracle's or mysql's command line tools.
You can see some more details here for example:
http://www.infinitezest.com/articles/using-sqlite-from-shell-in-android.aspx
As for "no such table" case - it really depends on where you store your database. You can choose (at DB creation time) where the database is stored - it might be the internal /data/data (usually) folder where your application resides or you could (mistakenly) create it in cache space - cache can be cleaned at any time whenever Android's OS finds that it needs more space, so this might explain why your database disappeared.
Another possibility is that instead of reinstalling the application, you uninstalled it and installed in two steps. Uninstalling application also deletes all the private data for the application (on most phones, but not on all), whereas reinstalling application (For example by clicking Run in eclipse) does not delete the data. In any case - in you application's onCreate you should recreate the database including all tables - always if you find it has not been yet created - because you never know if you run application for the first or subsequent time.
Please explicitly link to the example you reference.
The way I understand it, you create your own database at launch, unless the database already exists on the device, in which case the database creation is skipped. Correct?
If that is correct, then the only thing you need to do is uninstall the application whenever you update the database design (to remove the old database, with the old table names, etc) and re-install, so the database is recreated with the new table names.
Otherwise you will have updated application code that tries to work with an outdated database.
I added a table to a database that my application uses and wrote some code to work with that table. Everything worked fine for my on my phone and in the emulator, so I sent the update to the market.
This cause me to receive quite a few stack traces in the developers console cause by
android.database.sqlite.SQLiteException: no such table: flag
(flag is the new table).
This got me to wondering, are databases deleted when the application is updated? Presently in my application I am looking to see if the database exists, and if it does then I don't recreate it.
I didn't catch this before I sent out the update because I uninstalled the application before uploading the debug version.
I've since rolled out a quick update that has a try catch blocks around all accesses to the new table(which should have been there in the first place, I know, I know).
User data is not deleted, including databases.
Your DB has a version number. When you update your app, you advance the version number so that you can detect a present "old" DB.
This can be used to trigger a migration routine. In your case it should have added new table to the DB.
SQLiteOpenHelper is the answer.