I'm working for an iOS app that was earlier developed using phone gap. It is having a sqlite database for storing data. But now while developing the same app in native, I'm using core data for storing the data.
Now when the new native app replaces the old phone gap app on user's device, I want to copy data from already existing sqlite file into core data.
So when I run the application on device with phone gap build pre installed my app(native) replaces the old build as I'm using same bundle ID but I'm not able to find out the path to that sqlite file. Does sqlite file still exists in documents directory?
If you have an example old database file still installed on one of your devices you could try downloading the App off the device using the Device manager in Xcode.
Then you open up the bundle and search for your file. Then if you know its location / name you can simply access it, read it using some SQLite library and load the data into your CoreData backing store. Keep in mind you either want to mark it in NSUserDefaults or delete the old DB all together so your app does not keep on migrating ( And then maybe accidentally deleting new data from a user. ) I would choose for keeping the old one around for at least a version or 2 so you can verify that your migration works without bugs / deleting user data in the process.
Tip: It is probably a good idea depending on how big your database is to show the user some kind of progress or "migrating / optimizing db" while you're doing this. So you don't end up with the user adding more data to the database before you're done migrating.
Related
I'm using a sqlite database in my iOS app. I have all its tables definitions in an .sqlite file I've placed in the "Supporting Files" group of the Xcode project, and in code I copy this file to "Documents" to be able to perform database operations. While developing, I've found that, when I need to add/remove a table or change its fields and I remove the .sqlite file from "Supporting Files" to add the new one, then I need to uninstall the app from the device or the simulator and build again to get the new database.
How could I make changes in database tables by replacing the .sqlite file without having to uninstall the app? When the app will be submitted to the App Store, will the users have to reinstall the app when a new update with changes in database is available?
EDIT. Is it possible to replace the database and to keep/copy the data the user had in the old one? Or will user loose all the stored data when downloading an app update from the Store where the .sqlite database is replaced, as if he were installing the app from scratch?
I've never submitted an app to the Store yet, I need some guidelines about how to handle app updates if I need to make changes in database tables when having such database in an .sqlite file. I'm not using Core Data.
Thanks
for it, you need to modify database by using programmatically. Means, if you want to create/add new table in database then you need to add code like Create Table.... In this case, you can't use predefine database in code.
But if you want to use database instead of writing code, then you need to rename your database and copy all old database data to new database programmatically.
Thanks
I need a solution for a feature in an app my company is building. It is an IOS app for iPhone and iPad and we support ios5 and above only.
The end result we need is for the user to tap a button inside the settings area that dumps the apps internal database cleanly, attaches it to an email for the user to then address to whoever they wish.
Attaching to an email is not an issue. What I am concerned about is if it is reasonable to think that exporting a copy of an sqlite database to an email as an attachment would leave the user with a usable copy of the database. My customer base is not good about doing backups but the data is nevertheless very important to them.
Will a hot export of an sqlite database be usable, i.e. is this supported, or will the database be corrupt sometimes/always?
Keep in mind that all this function has to do is make it so that a usable copy of the database gets off the device and stored safely offline so that I can then walk them through restoring the database by copying it back into the device using iExplorer or PhoneView.
In the future we plan to add a robust export and import feature, but for now we are looking for a solution that we can implement in a day or less.
Thanks in advance for anybodys input and gasp some objective-c code that would dump a clean copy of an sqlite database in such a way that the database will be usable and not corrupted.
You don't need to make a hot copy of the database. When the user chooses the backup feature of your app, close the database, copy the file, and then reopen the database. You can now attach the copied file to the email.
I have a feature in my app for doing just this. I've never had an issue with a corrupt database file. As long as there are no active transactions running, the sqlite file should be OK to copy, especially if there are no open handles.
Another option would be to use the sqlite3_backup_init and related functions to copy the database.
I am updating an old iOS app which used sqlite database. I changed the database structure adding columns to existing tables. Now, I am testing it on my device. If I clear my old app from iPad and then run this new updated version on it, it is working fine. But if I have the old version installed on ipad already and test this updated version, it is somehow using the old database instead of the one updated. Can some one help me why it is doing this?
My guess and to try and make a simple answer for you is this. It's likely you updated the database in the project file - which means when you run it, your new db will exist in the bundle. files in the bundle cannot be updated, so its common practice to copy the database out of the bundle and store it somewhere in the ios sandbox. I usually use the documents directory to keep it simple.
Most likely what is happening is that when you run it over a pervious install, it see's that the file is already copied over to the device so it does not touch it, however on new installs, it probably sees the database is missing so it copies it there and that is why on new installs it works fine but existing ones it does not.
Look in the app delegate or your root view controller for code that checks for the existing database and copies the database over if needed on startup.
If you need to update the database on existing installs, you would need to force the copy.
Beware though if you have data in the existing database not to overwrite it if its important. If important data is stored there, you have to either do a little shell game of getting the data and importing into the new database, or maybe a simpler way, is to run the database schema modification commands on the existing database so it is the same.
again, beware and make a copy of the local database file before you run those commands, just in case.
best of luck
In iOS, a SQLLite database is really just a file. When you used the old app, it created the schema in the database file. When you load the new app, the data remains, untouched. If you want to use the new schema, you will have to detect the old schema and update the existing data. I believe that there are documented ways to deal with this. Bryanmac's question reference seems to be a good place to start.
When you install a new version of your app, iOS actually installs it in a new directory and then copies the contents of the documents folder from the older version to the one in the newer version. If you want to just use your new db, the best way is to have this db renamed or stored in a different directory inside your app's document store.
Here's a relevant article on updating An sqlite CoreData backing store on iOS:
http://www.musicalgeometry.com/?p=1736
I know there are similar questions on this subject but nothing that quite answers my query. I am aware that it is a bit of a newbie question!
I have an app on the AppStore which I will soon be looking to update. My binary contains a pre-loaded sqlite file with a list of data which the user starts off with. However, the user will extensively edit this information and it is crucial that that data is maintained through the update.
I am not changing the CoreData structure at all so won't be performing any migration but my concern is that when I upload the new binary the packaged sqlite file will overwrite the users existing data. I suspect that won't be the case but can anyone shed any light on it?
When updating an application the documents directory is untouched. Presumably your startup code checks to see if you have already copied the initial database from the bundle to the documents directory - this will work the same way after an upgrade.
You are testing this every time you run a new build on your device during development anyway - you've put a whole new version of the app bundle on there, and it doesn't kill all your data, does it? (does it???)
My app uses Core Data and I want some default entries to be inside.
What's best practices of how to do that?
If you're already loading the pre-load data via a temporary routine for testing in your current code there's no reason you can't use the sqlite file it creates in the simulator's directory (no need to write a separate Mac app).
If you're not already filling that db you can still write an iOS app that does it. Odds are you've already written the methods for adding data to your store so you can use them to import the pre-load data as well.
Either way you'd grab the sqlite file from the simulator's directory and add it to your app's bundle; on first launch you'll copy it into the appropriate place in the app's directory before pointing Core Data to it. If it's really large the downside is that there will be a copy in the bundle and another on disk, but there's not much you can do about that other than grabbing the data over the network.
As others have suggested, if the amount of data is small you can just import it at first launch, using the methods you've already written for adding data as part of the normal app's workflow.
See the CoreDataBooks example, which has sample code for copying a database at first launch.
EDIT: I've created a Core Data framework (read about it here: http://bikepress.org/?p=1120) that includes this feature.
I would just create a database and put add it to my target so that Xcode copies it into the app bundle. At the first launch just copy it from the app bundle to eg. the documents directory or wherever your app expects the database.
There is Core Data Editor at the app store. Alternatively you could build your own simple mac app just for this particular DB and manage it from there. If the amount of default entries is small, then you're better off storing it in a plist or something and loading it into DB after the first launch.
In iOS 5, my app was rejected if I put a database file into resource bundle. So, I have to download the database from internet instead.