I'd like to write an app which use Core Data and need some solution to insert information into my database.
Could I use phpmyadmin for filling the db and then just export to sql or I need another solution?
You could indeed populate an SQLite (note: not SQL) database directly and then use this with Core Data. However, I'd recommend against this, because it may cause maintenance problems down the road when the schema for Core Data's SQLite storage changes under your feet. Consider using Core Data itself to populate the database. And if you do this, you can fairly easily later on change the backing strategy of Core Data from SQLite to something else without incurring lots of work elsewhere.
More discussion:
Populating sqlite db created by CoreData
Any way to pre populate core data?
http://www.raywenderlich.com/980/core-data-tutorial-how-to-preloadimport-existing-data
http://forums.pragprog.com/forums/90/topics/2436
Well, phpMyAdmin is for MySQL and Core Data uses SQLite.
It's possible though. You could export as SQL in phpMyAdmin and replace one or two things to make it compatible with SQLite.
Also, see Christian Kienle's Core Data editor
Related
My app uses a preloaded SQLLite database with coredata bindings. I create the preloaded database file with a secondary app that has the core data bindings/model etc. I put the preloaded db into my app's resources folder and copy that to the writable documents folder when the app is first run.
My question is about migration. Since my app released, my users have been creating data and in my next release I want to change the data model and migrate some of the data to the new model. I'm just not sure the best way to do this. I've read about core data migration methods but they seem to require my app to be a core data project, which it isn't (though my secondary database-creating app is). Will I have to do this migration manually by issuing direct SQL statements against the db? And what about the core data bindings, will I have to manually update them?
I'm really just looking for pointers in the right/best direction. Any suggestions? Thanks in advance!
SQLLite doesn't really have any data migration tools like Core Data. Unless you count "ALTER TABLE". If the migration is very complex, or you think you will have more complex migrations in the future you could make a Core Data model that more or less lines up with the old SQLite model and import to it, and then migrate to a newer Core Data model, and then stick with it.
This is likely slower then ALTER TABLE though, or at the very least "not faster".
I have a website with mySQL database, parts of which I'd like to reuse in my iPhone app by populating CoreData DB (basically iPhone app is going to be an offline version of the website).
I am thinking of writing scripts which will translate mySQL into SQLite and then somehow feed the data into CoreData.
How would you accomplish this task?
Solution
Check out the following tutorial:
http://www.raywenderlich.com/980/core-data-tutorial-how-to-preloadimport-existing-data
TL;DR - uses a python script to write to the SQLite database in a Core Data compatible format.
Possible Drawbacks
If you've got a complex database, this could get messy fast.
If there's any errors in the format of the SQLite database, Core Data is not tolerant and you might get unexplained crashes.
Apple recommend that you never mess directly with the data store directly, which makes me a bit nervous of this approach.
Alternative
I'd dump the mySQL database to a CSV file, model the Core Data store in Xcode as unusual and write a quick and dirty importer within the application itself.
You could use cCSVParse to do the CSV heavy lifting.
I want to build an app that uses core data, but all the tutorials I found in the net didn't show if I can store a data without using the code it self.
Is there anyway to do it?
For example, i want to make a row of name and put there couple of names.
I've just read the book "Pro Core Data for iOS" from APRESS it covers Core Data very well. I recommend this by heart.
You can try Core Data Editor. But it's not cheap.
You can use SQLite directly without Core Data; there you'd have your SQLs in your own hands. Your can use Core Data and debug SQLs issued by the framework, of course if using SQLite as the store.
Core Data works also with binary and XML format (the latter not available on iPhone): passing following argument to the application:
-com.apple.CoreData.SQLDebug 1
Other than that, you could probably use SQL to access Core Data SQLite store, since it is all SQL, but it is not recommended.
Unfortunately Core Data is all code. However, CoreData is an api that helps you create, save, load data from the database, it uses SQLLite in an easier fashion.
If you need very complex data storage then by all means use SQLLite directly. But, if it's just simple data storage of names, emails, booleans, etc, then i would recommend CoreData.
I'll give you a link that it helped me greatly when i wanted to integrate CoreData for my app.
CoreData Tutorial
Good Luck.
I am new to iPhone development and want to know which database you use to program an iPhone/iPad?
I have heard its SQLite, are there any alternatives to this?
The application I am programming is like an online shop however you can't buy products, only view their details.
You should use CoreData for that. CoreData is a database abstraction layer which uses SQLite to store your data. Or you could use SQLite directly. But I would prefer CoreData.
Core Data Programming Guide
Core Data Overview
If you have any plan to use the database file outside iPhone e.g. in other computer, or data input program to populate data, then SQlite is the best choice. CoreData modify the fields name when you create the database inside XCode. But if the data is only accessed by your app in the iPhone, best choice is CoreData.
If you want to run complex sql query then sqlite is better. Read about NSPredicate, what type of query you can do there.
SQLite is the master choice here!
As an alternative, I would suggest you the simplicity of an XML file.
You can also use NSUserDefaults if u have less data to be stored in your database.
http://icodeblog.com/2008/10/03/iphone-programming-tutorial-savingretrieving-data-using-nsuserdefaults/
If the data to be stored is more then go for sqlite
I am sitting on a ton of data in a SQL Server 2005 database, from which we dump Access databases as a cache.
I want to create an iPhone app based on Core Data that can use this data from my SQL Server 2005 database, or the Access dump.
Based on all of the Core Data tutorials and documentation it appears that I have to use Xcode to create a Core Data schema and populate that schema using Xcode.
SQLite seems like the right thing to act as a dump point, then use SQLite APIs. But this doesn't bridge nicely to Core Data in my mass data scenario.
Apple has obsoleted the SQLite Books Example seemingly with the sole intent of making sure that you use Core Data and not SQLite.
Has anyone come up with a dump scheme for data locked in an Access or SQL Server 2005 DB into an iPhone friendly format? I don't care if it is Mac OS X code, iPhone code, or .NET code... Anything?
In my case I am talking about 26MB of data that I would like to have an offline cache to for my application.
26MB of XML seems like a bad idea. 26MB of SQLite seems like a great idea. 26MB of Core Data seems like an even better idea.
Thanks in advance,
--Batgar
You could create an Objective-C app in XCode using the FreeTDS library to pull data down from your MSSQL database and populate your CoreData store.
http://sourceforge.net/projects/freetds/
There's also a commercial product that provides an MSSQL ODBC driver for Macs, which you could then call from your data migration code:
http://www.actualtechnologies.com/product_sqlserver.php
If that doesn't work, you can set up the MSSQL database with an IIS front-end and retrieve the data using XML queries. Starting with MSSQL 2000, there's a way to query the server directly via HTTP and get back results in XML without having to write any ASP/ASP.NET code.