5

The FMDB page just offers the cvs checkout. Maybe someone out there wrote a good tutorial on how to use FMDB with sqlite3 on the iphone?

  • If you want written tutorial then follow this link : http://www.techotopia.com/index.php/An_Example_SQLite_based_iOS_8_Application_using_Swift_and_FMDB – shahid610169 Jun 15 '16 at 04:46

4 Answers4

2

FWIW I have found CoreData to be buggy and unreliable, especially WRT its automatic model upgrading. I'm switching back to using raw SQLite and FMDB.

esilver
  • 27,713
  • 23
  • 122
  • 168
1

Check out this tutorial - I found it absolutely brilliant. Now using storyboards and ARC (automatic reference counting) myself, so had to modify the navigation parts a bit and skip the dealloc code, but if you are comfortable with xcode and sort of know what's going on, this is perfect. Nice explanations along the way, and no farting around: http://www.youtube.com/watch?v=2Ojr7DZLghk&feature=channel&list=UL

I downloaded the latest FMDB files from their source - instead of using his. The latest files are updated for arc, and I had no issues. Get them here: https://github.com/ccgus/fmdb

InRainbows
  • 103
  • 1
  • 9
1

The source is the documentation, apparently.

The question, though, is why aren't you using Core Data?

Gus effectively compiled FMDB for the iPhone because Core Data wasn't available. Now that it is (as of 3.0), the need for FMDB is diminished.

Obviously -- if you need code portability, then the direct sqlite APIs are likely the way to go.

If you need data portability, then a wrapper like FMDB is probably the right answer.

If your portability is achieved through fully native apps with a client/server data flow architecture (which will offer the best per-device user experience, though at a potentially greater development cost), then Core Data is typically the best answer on iOS.

bbum
  • 162,346
  • 23
  • 271
  • 359
  • 3
    c'mon. Everyone tells me Core Data is the solution. But why should I give up about 40% of my customers just because I want to be lazy? That's silly, in my opinion. Of course they blend us with perfect upgrade statistics all over the place. But from my experience, iPod touch users think: "WTF? Why should I pay for this? Don't need to type so much. I don't write SMS or E-Mails. Don't need copy&paste. Don't need that large keyboard." so as long as they find useful apps for their older OS, they're fine with that. CoreData would be nice to have, but not this year. –  Aug 14 '09 at 16:45
  • It's not laziness that's driving many people to Core Data. There are significant performance benefits to be had: http://stackoverflow.com/questions/1263723/cocoa-touch-when-does-an-nsfetchedresultscontroller-become-necessary-to-manage-a/1263845#1263845 . Additionally, it makes things like undo and redo practical. You have to ask yourself: by staying 2.x-only, are you at a disadvantage to your competitors who have adopted 3.0 features? – Brad Larson Aug 14 '09 at 17:35
  • 2
    40% is not accurate. The figure would be more like 20%, and is declining rapidly - and if your application is good, people will be compelled to move to 3.0 to use it. The simple fact is that most iPhone/Touch owners upgrade pretty rapidly, if they are buying applications - because a large number of application writers take advantage of very real gains in using the new version. – Kendall Helmstetter Gelner Aug 14 '09 at 19:53
  • 3
    You also have to ask how much value there is in significantly lowering your time to market. Core Data solves a series of really hard problems, all of which can significantly reduce your time to market if you embrace the patterns fully. Most developers grossly underestimate the time & effort required to deal with the raw SQLite API directly. As well, most developers that write SQL by hand do it wrong (myself included-- which is why I don't do SQL directly unless it is the solution of last resort). – bbum Aug 15 '09 at 20:46
  • Maybe you're right about this time to market theory. For me, I think even 10% would be a reason to try to stay compatible with older versions, unless I don't constraint myself too much by that. I'm gonna have to think once more about all this stuff. –  Aug 16 '09 at 07:28
  • a reason someone may not want to use CoreData is in a static library. There seems to be no simplified way to create a model in the library without having it also in any project which includes the library. Having to include the core data stuff in both library and project defeats the purpose of having a library! – james Jun 30 '11 at 13:47
  • That is a rather minor reason to give up all of the efficiency and intimate integration of Core Data with the system vs. Wrapped SQLite.... – bbum Jun 30 '11 at 15:00
  • Core Data is not always the option. For example I am working on a project where I had to encrypt the whole sqlite database file. I was using SQLCypher(yes I know about data protection) and I was left with raw sqlite api. FMDB was my choice for that. This is just one example. I believe, there can be other scenario as well. – Max Feb 11 '12 at 19:03
  • Which is why I said "diminished". There is still a need, but you are making a major-- sometimes necessary-- tradeoff. In your case, you gained the use of encryption to fit your needs while sacrificing iCloud integration and other features resulting from Core Data's tight integration with the system. – bbum Feb 12 '12 at 00:51
  • 3
    Another reason I can think of for wanting to stick with a sql system over core data, is for cross-platform app production. having all the data that I want to be pre-populated into my app wrapped up into a common spot; makes it easier to produce versions of it in other platforms, but only iOS supports "Core data" while all of the platforms I'm working with claim to support sql so when the data changes (as it will from time to time) I'd rather not have to mess with recoding the data for each platforms special database method if I can just package the data once and have it be useable everywhere – Kit Ramos Jul 11 '12 at 03:43
0

The xcode project in the svn repository has a fmdb.m file in it with plenty of usage examples to get you started.

JakeK
  • 61
  • 2