On Tue, Feb 7, 2012 at 7:59 PM, David Barrett <dbarr...@expensify.com>wrote:
> > > Or, perhaps you are running the command-line tool on a >> different machine where it is not able to access the WAL's database-shm >> file in shared memory. So the command-line tool reads a one page of the >> database which indicates the the content it is seeking is found on some >> other page X. But by the time the command-line tool has loaded page X, >> the >> server has already shifted the content to someplace else. The page that >> the command-line tool loaded is no longer formatted as the command-line >> tool expects it to be, causing exactly the error shown above. >> > > I think this is a very likely candidate. There is nothing particularly > fancy about the deployment: no VFS, no custom locking, etc. But we use > sqlite3_enable_shared_cache() to disable the cache (even though it's > disabled by default) -- combined with "PRAGMA synchronous=OFF" (and add in > WAL just to make it more complex). Could that explain the behavior we're > seeing? > There are no known limitations on the use of PRAGMA synchronous=OFF, WAL mode, and shared cache together. > > Basically, I'm curious if it's a known issue that the combination of the > above settings creates a situation where the command-line client can't be > relied upon -- and that the client will incorrectly report a malformed > database. > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
