• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Please don't build your own SQLite without reading this (was: Re: Sqlite Version???)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Please don't build your own SQLite without reading this (was: Re: Sqlite Version???)


  • Subject: Please don't build your own SQLite without reading this (was: Re: Sqlite Version???)
  • From: Alastair Houghton <email@hidden>
  • Date: Thu, 20 Jul 2006 11:08:15 +0100

On Jun 21, 2006, at 3:57 AM, Jerry Krinock wrote:

on 06/06/20 18:43, Rick Langschultz at email@hidden wrote:

If i create a program that uses a SQLite datastore to save files
which version of SQLite will my app use to save files? Is it the
latest up to date version of sqlite on the system or another version?

The SQLite that ships in Tiger is version 3.1.3, March 2005, and I found it
was quite painful to have things not work per current SQLite documentation,
and then have to dig through the version history to find out the bad news.


So, you'll either want to use CoreData, or else if you need to support
Panther, build an SQLite static library yourself from the latest SQLite
source code. Regarding the latter, search the archives of
email@hidden for a message I wrote about a month ago, which
explains how to build it using Xcode in 5 minutes.

I know this is nearly a month old now (I only periodically scan the list at present), but please don't just go building the official SQLite sources because they don't work right for files on e.g. AFP or SMB shares, because the locking code won't work there. (That's not to say that AFP or SMB don't support locking, because they do, it's just that it doesn't work through the fcntl() function.)


Apple's version includes extra code to fix this problem, so if you're going to build your own version of SQLite, you need to port that code (or fix the issue yourself) otherwise it won't work for any users whose home or data storage is on such a filesystem, which is quite a few of us (me included). Either that, or you could turn locking off, but only if you're sure that your application will never need it (and again, please remember those of us with networked home areas... I can run your app on two machines against the same file if it lets me, so if you have no locking whatsoever you might lose my data :-().

I ported Apple's locking code to the latest SQLite (3.3.6):

  <http://www.alastairs-place.net/archives/000085.html>

I'll also add that you may not actually want to rely on SQLite's locking; for instance, if you store your app's data in a bundle, you might want to create a lock file inside the bundle to indicate that the data is in use... then you could detect the lock file and prevent people from opening the data on two machines at the same time (for instance).

Kind regards,

Alastair.

--
http://www.alastairs-place.net


_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Prev by Date: Watching System Configuration
  • Next by Date: nib example
  • Previous by thread: Re: Watching System Configuration
  • Next by thread: nib example
  • Index(es):
    • Date
    • Thread