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.
Related
I created an application which works with database. I have installed that application on my both phone. Now, while using both devices i cant manage data because if transactions that are done in one device, does not show in another device, to do that i backup database from one device and restore in another device but restoring that database will ruin the database and transactions which are already in that device.
So, the thing is, I want to sync data between two of my device such that data from each device should be in another after sync
If your problem is the conflicts, you can resolve the conflict by writing the more recent records over old records. to do this:
Define a field in your records called lastEdited. you can choose a date or timestamp base on what suit you best, Though if you don't plan on displaying this values it's better defining this field as long for easier comparison later.
Each time you edit a record update the lastEdited to the current time.
After your passed the backed-up Database, read records one by one; Insert the new one but in case of conflict resolve it by comparing the lastEdited field between two records.
Hope it helps you ^^
Cheers
Well, I'm building a app in both iOS and Android and both app needs to be syncronized with the cloud DB MySQL. Both the apps works offline so I need all the insert and update functionality. Delete is probably not going to be used but still I'd like to know.
Well, what I'm looking here is the solution or ideas or algo that's needs to done to achieve this.
I have kept CreatedOn and LastSync as timestamp column on each table.
Now the problem is should I always keep checking all the rows and all the columns everytime?
What I think is I should keep ModifiedOn column on all the tables and check that with LastSync for every device id. What do you guys suggest?
Maybe it's not the answer you are waiting for, but on the project I'm working on, we are using Azure Mobile Services. There is an Android and iOS SDK where they implemented synchronization between offline database and Azure (just like in Git you can call push and pull methods).
There are some limitations (TableStorage is a limited MSSQL storage), but you should check it out.
I know it's about two years overdue , but I've been doing the same thing (Android App that syncs with web api and postgresql)
What I do up to now (still researching if it's the best way, which is how I found this question) is that I keep a last_update field with a timestamp on when the data was last_updated and an altered field with a boolean on whether the data was altered (by a user action on the device)
So when I perform the sync:
I first copy the database to a backup (in case there is a problem)
I send all the rows that are marked as altered (the server handles conflicts)
then delete them
after that I find the max(last_update) value,
I subtract one minute from it
Then request all rows that have been updated after that value,(this will also also include the data I have sent because there is no way , unless there is a problem, that a row is set to altered with a last_update before the last non altered row)
It may cause some duplicate data being transfered (especially if you make A LOT of changes frequently) but in my case it's a rare phenomenon
I have an SQLite database with records being inserted into it for my Android app.
I am inserting the answers to on screen surveys, with one answer saved per row in my table.
My surveys have 20 questions, and it inserts the answers correctly to the database for the first survey, but then when I insert the answers for the second survey (programatically the same questions, just done again) it malforms the database, but never throws an exception or anything. I run an integrity check before and after and it always returns true.
The unusual thing is that it is only malformed when I try to look at the table on my computer. I tried using the SQLite Database Browser tool, TKSQLite tool, and then opening the DB from the supplied sqlite3.exe, and they all seem to show the DB as malformed. Although the TKSQLite tool notifies me that the table is malformed, I can get the data in other tables. The SQLite Database Browser just shows no data in the table, and sqlite3.exe won't open any tables.
The very unusual thing is if I query the table in the app and print the cursor rows out to log cat, or use the data within the app, all the data is there.
Has anyone seen only partial malformation without an exception being thrown? I would like my database to be pristine...but if my data is there can I hope that it won't get any more malformed?
I worked with SQLite databases for a few projects now doing similar things, and this is the first time I am seeing only partial malformation.
If it will help I am using the Acer a501 tablet programming on Honeycomb 3.2
Additionally, I am accessing the database using a static singleton, to avoid opening and closing the database too often for each insert, and originally inserted via SQL commands using execSQL(), but have also tried using the SQLiteDatabase method insert() to no avail.
We figured out why the database was malforming but not on the device. The tablet we are using is counted as a Portable Media Device according to Windows, and there was some issue when we copied it from the device to the computer. Using a thumb drive to copy to from the device and then from the thumb drive to Windows solved the problem.
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.
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.