Thanks for the suggestion, I think I'll try this. I probably need to detect the kind of error and use some retry-mechanism ...
2014-06-05 13:35 GMT+02:00 Richard Hipp <d...@sqlite.org>: > 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 > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
