On 26 Feb 2015, at 12:26am, Dave Dyer <ddyer-sqlite at real-me.net> wrote:
>> Do you have any multi-access things going on ? Two or more computers, >> applications, processes or threads trying to access the database at the same >> time ? > > No, but it would be normal for the database to be on a different > computer than the sqlite client, and be using whatever networked > file system is common. The culprit clients seem to be macs, we're > still seeking more information about the specifics. Sorry to have to tell you, but almost no implementations of network file systems implement locking properly. So any situations involving simultaneous writing can lead to corruption. But if you do not have simultaneous writing, there's no good reason for database corruption. What you need to find out next is OS version that the computer holding the file is running. File system that the disk the file is on is formatted in. OS version that the computer accessing the file is running. Network protocol used to access the remote filespace (SMB or AFP or something like that). Earlier you wrote > I suppose that this might be a sqlite bug if the "insert records" step > and the "maintain indexes" step were separated by a disk error and the > rollback of the failed transaction was incomplete. Now you've told me that you are checking the result codes returned by all calls, this would have to be a significant bug in SQLite and I don't think I've heard of any other reports of it. Simon.
