Re: DBD::SQLite "file is encrypted or is not a database" in running application

Not sure if this will be helpful or not, even if it is correct.

Based totally upon your description -- or more correctly, my interpretation of your description -- this sounds like a classic case of corruption due to overlapping concurrent writes to a system that has no protection -- locking -- against it.

If that is a possibility -- hard to tell from the description -- then my first step to confirm the diagnosis would be to implement a very simple locking mechanism. On windows I'd use a CriticalSection as a starting point -- it's not the most efficient mechanism, but it is simple and robust. If that confirmed the diagnosis I'd then look to use one of the more efficient, lightweight mechanisms.

I can't advise on appropriate mechanisms for *nix.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re: DBD::SQLite "file is encrypted or is not a database" in running application

Replies are listed 'Best First'.
Re^2: DBD::SQLite "file is encrypted or is not a database" in running application by stevieb (Canon) on Oct 09, 2016 at 22:47 UTC
This is where I was leaning as soon as I was able to get the error output of my crashes. Tomorrow, in hopes of repro-ing in a more consistent way, I'm going to throw together a perl script that spawns off a bunch of children that continuously write to the db simultaneously to try to force the same crash, then I'll play around with locking code, and test it with this mentioned setup. I'll post back on this thread with what I find, and how I get around to possibly solving it.	[reply]
Re^3: DBD::SQLite "file is encrypted or is not a database" in running application by Marshall (Canon) on Oct 10, 2016 at 00:38 UTC
You might find this of interest: SQLite Locking. SQLite has a robust locking mechanism. For a write, a connection has to acquire an exclusive lock on the DB. This can significantly affect the performance in multi-writer situations. Any failure in the locking mechanism would be a high priority bug.	[reply]