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

Reply via email to