views:

45

answers:

2

Hello.

I have an SQLite database in the first version of my iPhone application (which is on the app store). Now I want to roll out the second version of the application, which also has an SQLite db in it.

I understood that upon update, the SQLite database is removed and then the new one is added. I don't want this to happen, since that database holds some information that the user has saved. It wouldn't be good if it is deleted upon update.

Question is, how do I transfer the data from the old SQLite (old version) database into the new one? And how can I test the version update process that would happen on the App Store?

Any help would be greatly appreciated. Thanks.

+1  A: 

This isn't something I've personally tested, but to the best of my knowledge:

  1. Your first question's been answered, and the short of it is that you're out of luck if your sqlite db isn't copied to the Documents directory, since the entire app bundle will get replaced on upgrade. Assuming christo16 is right, and assuming that your already-shipped app didn't copy the db out to Documents, you might want to ship an interim version that does do this. Then it'd just be a matter of making sure a critical mass of users have installed the interim version before you roll out the db updates.
  2. Re: testing. You should be able to test the upgrade behavior by installing your build via iTunes instead of via Build & Run. It's been awhile since I tried it...following the instructions for an ad hoc build should do the trick, though it might be overkill.
clozach
Thanks...I guess that makes sense...but what if there are a couple of changes to the new database. E.g. in this new version, I added a new table, but the other table was left untouched. What would be a good workaround around this?
Andrei
+1  A: 

The answer is: implement versioning in your app from the very start :-)

In this case, you can consider an app with no version information to be version 1. What I would do is store the version of the database somewhere (probably inside the database itself). When the database is opened, check its version against what version the app expects, then make any schema changes as needed and update the stored version number.

If you haven't copied the database to the app's Documents directory, then this is all moot because it would be read only anyway. Otherwise, the contents of the Documents directory are preserved between updates.

To test the update, just start with a fresh copy of the previous version on your device. Then install the new one (build and run will do just fine). You do keep old versions of your app, right?

Brian
Err...I definitely should keep old versions of my app. I'll start from now anyway. But I understand what you're saying and it seems like a pretty good idea. It is a bit of a trick to insert the version of the app into the database, but a good one nonetheless. So the idea is that when the application launches, you check to see the version number. If the db has a lower version number than the application itself, then you start some SQL statements (like create new table etc.) and update the version within the database, so that on the next startup of the app you won't have to update anything again
Andrei
Right, though I've found it's better to maintain separate version numbers for the app and the database. Otherwise, if you update the app but leave the database the same, the app might mistakenly apply updates to the database.
Brian