D.Richard Hipp writes: | Good question. I suspect that whatever is going wrong has little or | nothing to do with SQLite, though. What other debugging steps have | you taken?
I could not think of anything very useful to try, but in any case I found pretty quickly that the problem was the fact that activity elsewhere had nearly filled up my root partition. I don't know exactly how this would explain the observed behavior but I would speculate that uncommitted changes were lost because of some temporary file cache, but committed changes made it to the actual database file on another partition? (In any case my code should find these problems; it does not have adequate error checking in it to see if each statement that changes the database has been successful) Simon writes: | Are the changes actually making it to the file on disk ? | In other words, if you do _open(), INSERT, _close(), does the disk file get updated ? | What PRAGMAs are you using ? Moot questions now, but yes the changes made it to disk if I did a commit after each statement that changed the database. Very simple database, no "pragma"s at all. Ryan writes: | I imagine you are using some wrapper, possibly a JAVA one, PHP or | a PEARL one, I think your web service may have updated so the | supported wrapper updated with possibly a new default setting or such Excellent guess given what I reported, but I neglected to say there is no web service -- the server is just my own home computer, everything updated would be by me, but nothing relevant was updated at the time the problem arose (I chased a few red herrings along these lines). | Either way, next time you write in, please mention exactly which | platform, which wrapper (if any) and perhaps the extract of the actual | code that does the calling. Even if it is not an SQLite problem | directly, there are likely many people here who use the same | platform/wrapper that you do (perhaps even the wrapper's author). I mentioned I was using python and its sqlite3 module, but did not specify I was using it in simplest possible default mode, just opening the connection with no arguments. I didn't need to know more before -- with a simple single-threaded program I thought (and still think) it should be fine to just open a connection, do stuff, commit and close. This appears to be true, but reading more about the sqlite3 module, what it does in the default mode is a little tricky with respect to when commits are done. I didn't even know that outside transactions, SQLite by default itself commits automatically after each statement, which I would not have wanted. However, the python module by default implicitly inserts "begin"s so that statements are grouped into a transaction that one then has to explicitly commit Thus, that the commit I did after them was necessary for that reason, and not the reason I assumed, which was that SQLite itself needed the commit even outside transactions. (I think I would prefer the module's option where it keeps SQLite in autocommit mode and one then has to make one's own transactions explicitly). None of this, as far as I can see, should cause what I observed, however, as it was all within the same connection. It was very mysterious but as Dr Hipp correctly speculated, had nothing to do with SQLite. Thanks for all the replies everyone. -- Sent from: http://sqlite.1065341.n5.nabble.com/ _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users