On Thu, Jun 5, 2014 at 7:21 AM, Lasse Jansen <la...@lasselog.com> wrote:

> Hi,
>
> we have a Mac app that uses CoreData which internally uses SQLite. Some of
> the queries are not expressible within CoreData, so we send them manually
> using the sqlite library that comes with Mac OS X. Now some of our users
> have reported that their database file got corrupted and after some
> researching I think it's because of multiple copies of SQLite being linked
> into the same application as described here:
>
> http://www.sqlite.org/howtocorrupt.html
>
> Even though we link CoreData to our application and CoreData uses sqlite
> internally we still have to explicitly link libsqlite as the CoreData
> version of sqlite is inaccessible due to the usage of
> two-level-namespacing.
>
> So I have two questions:
> 1. Can this be solved without dropping CoreData?
> 2. If not, is there a workaround that we could use until we replaced
> CoreData with something of our own?
>
> I'm thinking of this:
> As the problem seems to occur due to calling close() and we only use
> libsqlite for read-only access, would just not closing the read-only
> database connection prevent the corruption?
>

The problem is more than just close(), unfortunately.  Certainly the fact
that close(open(zFilename)) deletes all locks on any file descriptor for
the same file is a big problem.  But it is not the only problem.
fcntl(F_SETLK) has its own set of similar problems.

Now if you did this:

(1) Open the read-only connection using the brand-new "nolock" option
available in 3.8.5 (to disable the use of fcntl(F_SETLK).

(2) Keep the read-only connection open forever, or at least until after all
coredata connections are open.

Then it might work.  However, with locking disabled, your read-only
connection might try to read the database file simultaneously with other
process writing it, which would make the read-only connection think that
the database is corrupt.  This would be a difficult thing to clear without
closing and reopening the database connection, unfortunately.






-- 
D. Richard Hipp
d...@sqlite.org
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to