On 16 Mar 2010, at 5:17pm, HLS wrote: > Once approach is to queue any updates/deletes when the database is > locked with a select request. So when a fetch ends (like in the > GetNextxxxx function), it will check to see for any pending updates > and process them. > > Does that sound like a viable approach with SQLITE3? > > Hmmmmm, this would not address possible client code that can break > from a loop before reaching the end of select query.
For the approach that involves queueing write commands, you do definitely need to know when a SELECT has finished with the database. But SQLite depends on that anyway, and there's no reason why it shouldn't depend on correct usage of the API including sqlite3_finalize() . I have one installation where it's okay for SELECT commands to return results which are slightly out of date, but new data becomes available at sparse and irregular intervals from many sources. Consequently, this system delays write commands until there has been no access to the database for one minute (checked by touching a file whenever sqlite3_prepare() is done). In this particular installation this makes perfect sense, because the patterns of reads and writes is well understood. However, for some random installation for a random use of SQLite it would be disastrous. You may be in a situation where you can develop a protocol which fits your particular use of SQL very well even though the solution would be useless for a more general use of SQLite. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
