On Thursday, July 22, 2010 6:14 PM, Dan Kennedy wrote:
> On the other hand, if the only client connected to a database > does not disconnect cleanly (i.e. it crashes, the system crashes, > or the client exits without calling sqlite3_close()), then it > leaves the *-wal file in place. In this case, when the next > client connects to the database file it has to read the entire > *-wal file to reconstruct the wal-index. If the *-wal file is > large, this might take a while. > > So one thing to bear in mind when using WAL mode is always to > call sqlite3_close() on all database handles before process > exit. Otherwise you may leave a big *-wal file in the file-system > which will need to be traversed by the next client that connects > to the database. > Hi, I've read this thread with interest, but it leaves me with one particular question to which I haven't found a definitive answer elsewhere. I am using sqlite in embedded devices. In this case, there is no "shutdown" and the application never ends, so at the moment it never calls sqlite3_close. The user will simply turn off the device, when they're done. Am I right in saying that WAL mode is therefore not really compatible with this, since the sqlite3_close call is never made? Or is this what I use the sqlite3_wal_checkpoint api function for instead, or have I misunderstood its purpose? Or... do I have to encapsulate blocks of accesses to the database inside their own sqlite3_open/sqlite3_close calls (surely not!)? Thanks for helping with my confusion! Andy _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
