Although I started writing this as a cheat-sheet for myself (after many hours of struggling with this by trial-and-error), I figured it would be helpful for other iPhone developers who’d like to take a mySQL database online and migrate it to their current iPhone project. While other tutorials cover how to read the database into the application from the coding point-of-view, this is just to make sure you get your data uncompromised from your existing mySQL database into a new SQLite DB that your iPhone app can read.

First of all, here’s what I am currently using; I am including versions in case that’s relevant to your situation:

• MySQL 5.0.81
• MySQL charset: UTF8-Unicode (utf8)
• MySQL connection collation: utf8_unicode_ci
• phpMyAdmin – 2.11.9.5
• SQLite Database Browser 1.3 (includes 3.3.5 of the SQLite database engine)
• iPhone Dev Kit – 3.0
• XCode 3.1.3
• SQLite 3 framework found at /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr/lib/libsqlite3.dylib

You can try other solutions for importing the data into a SQLite format, but I’ve had the best luck with Mauricio Piacentini’s SQLite Database Browser. Other options you might want to try include a Firefox plugin.

Here are the steps, using SQLite Database Browser:

1. log into phpMyAdmin, select your database and go to Database> Export.
2. On the export tab, make sure all databases are selected, and the “SQL” radio button is selected.
3. Select ANSI from the pulldown for export compatibility.
4. Uncheck all options under Structure and Data, but leave each section checked.
5. Save as file should be checked, and probably be via ZIP or GZIP, just in case.
6. Click the Go button to download your file.
7. Extract the file and open it up in your favorite text editor (I use BBEdit).
8. Find the first CREATE TABLE line. We need to modify these by hand to simplify the table creation so that SQLite doesn’t get confused. For example, my file came down looking like this after the comment section ended:
   
CREATE TABLE dictionary (
id int(11) NOT NULL auto_increment,
word varchar(100) NOT NULL,
adjective tinyint(1) NOT NULL default '0' COMMENT 'is an adjective',
noun tinyint(1) NOT NULL default '0' COMMENT 'is a noun ',
intro tinyint(1) NOT NULL default '0' COMMENT 'is an intro',
PRIMARY KEY  (id),
UNIQUE KEY words (word)
);


   You’ll want to edit this to remove pretty much everything but the most basic information and normalize the data types to SQLite 3 Data Types, which are TEXT, NUMERIC, INTEGER, REAL, or BLOB. Your CREATE TABLE should look something like this:

   CREATE TABLE dictionary(
id INTEGER PRIMARY KEY ASC,
word TEXT,
adjective INTEGER,
noun INTEGER,
intro TEXT
);

   I was using id as a primary key so I’ve added “PRIMARY KEY ASC” after “id INTEGER”. (Primary Keys are aliases to row IDs in SQLite, if you have questions read this.)

   However, I’ve noticed that the SQLite Database browser exports SQL in the even more simplified format with no datatype specification as such, which also seemed to work for me and may work just as well for your needs:

   CREATE TABLE dictionary (id, word, adjective, noun, intro);


9. Continue going through your text file and fix all CREATE TABLE lines as in #8, above.
10. Check your file text encoding. BBEdit may default to Western (Mac OS Roman), which worked for me, but if you have problems you may need to set it to Unicode, depending on your character set.
11. Check your file for suspicious characters that might cause the import to choke. Single quotation marks used as apostrophes show up as escaped by themselves; for example you're becomes you''re. This seemed to import fine as long as the other guidelines are followed. Here’s what an example INSERT should look like:

    INSERT INTO dictionary VALUES(305, 'ne''er-do-well', 0, 1, 0);


12. Check your line endings. BBEdit defaulted to Unix (LF) which worked for me.
13. Open up SQLite Database Browser, create a new database (.db) file, and import your SQL text file by selecting File> Import> Database From SQL File from the menu.
14. Check your data by clicking the Browse Data tab and make sure everything came in all right. If not, go back over the steps. Look for weird characters, text and line encoding issues, and syntax issues. The only two commands in your file should be CREATE TABLE and INSERT, although technically it should probably begin with BEGIN TRANSACTION; and end with COMMIT;

Again these steps were derived mostly by trial-and-error, so there may be issues particular to your DB that these guidelines didn’t solve. Please feel free to add any corrections, tips, and questions to the comments area.

Also, I know that with the iPhone OS 3.0, Core Data can take care of a lot of database functionality for you. I’d love to hear how people made the transition, and especially how anyone got a pre-existing SQL database into a Core Data store.

I just saw that Apple has put on its home page now has a public response to justify its App Store policies.

http://www.apple.com/hotnews/apple-answers-fcc-questions/

Of course the FCC is primarily interested in its rejection of big, important apps like Google Voice, and not indie developer apps, so Apple was able to gloss over its political censorship of apps like Freedom Time (See section 5, above), and not even include any rejected political content app in its list of “representative applications.”

To me, rejecting an app for speech reasons is much worse than for technological competition reasons, but maybe that’s because I am someone who cares about the first Amendment, something that has been shoved to the back of the bus while greasing the wheels of the free market machine.

Thanks to Brad at Bent Media for pointing me to this excellent essay by Joe Hewitt demanding the end of the App Store approval process as we know it.

Well, I’ve given up on trying anything too humorous for the App Store— if you have to finish your idea BEFORE it’s approved, what’s the point?

But that hasn’t stopped others from trying ideas that are beyond the pale, and some that are so truly tasteless, that our little attempted joke at the expense of the outgoing president of the US seems really sterile by comparison.

I’m sure you’ve all heard about the “Baby Shaker” app controversy. It got the press scrambling to look at Apple’s app approval stories once more and, after months of assuming the whole thing had been relegated to its proper place as a footnote in the appendix of the Apple history books, I got contacted by ABC News and the Wall Street Journal over Apple’s rejection of Freedom Time.

• Banned by Apple: 9 iPhone App Rejects – ABC News (page 5)
• Apple’s Gatekeeper Role Draws Scrutiny – WSJ.com

All very exciting, I suppose, except that the reporters never seem to get the gist of what I was trying to say, which was this:

If Apple makes itself the gatekeeper, it is actually causing itself the problems it’s trying to avoid. By rejecting an app that makes fun of Bush, but accepting one that lets you kill babies, it implies that it disapproves of one and approves of the other. If someone had made this application for Windows, Mac OS X, or any other desktop system, no one would accuse Microsoft, Apple or Linux for not building an OS that prevents Baby Shaker applications from being installed. Apple made both a whole lot more work and a whole lot more controversy for itself by insisting on manually gatekeeping for every single app that goes in the store.

It started out as Court’s idea as a way for me to learn Apple’s Xcode, Obj-C, and the iPhone development kit, but it kind of took on a life of its own.

There was a pretty steep learning curve, and registering to be an iPhone developer (although very affordable) and getting your device provisioned and such was a little more difficult than I’d hoped, once you’re over that hump it’s really kind of fun.

Court done the graphics up, Texas style. Originally, we were going to call it “Freedom Clock” as in Freedom Rock, but I found a bunch of public domain audio clips where W. says “time” in them, such as “It’s time for a leader” or “It’s time for a new administration to deal with the energy crisis” that hilariously illustrated the current situation.

More information is available on the Freedom Time for iPhone page.

Submitted to Apple for review; look for it in the App Store soon!