Please be advised that updating/inserting/deleting from the table while you're executing select on it has undefined behavior in SQLite (if you do that on the same connection) and is considered dangerous. Doing that from different connections is possible only if have shared cache turned on and read_uncommitted set to 1. If you don't use shared cache and turned off locking on VFS level then you can easily get database corruption.
Pavel On Tue, Mar 16, 2010 at 2:12 PM, HLS <sant9...@gmail.com> wrote: > Thanks Simon. It just seem so simplistic that SQLITE3 does not allow for > > Open Cursor > for each fetch > Issue Update based on ROWID > endfor > Close Cursor > > The row fetched is already complete, or the rowid in the table is no > longer "sensitive" to anything but a update whether it was opened or > not. The "current" cursor is at the next record ready to be fetched, > not the one that just been read. So it would seem it would be > possible to implement a wrap a lock on the rowid update. > > I had to see if this is possible with the VFS notes Pavel pointed me > to perhaps, or even been looking at the feasibility of changing code > (which is the last thing I don't want to do.<g>) > > On Tue, Mar 16, 2010 at 1:31 PM, Simon Slavin <slav...@bigfraud.org> wrote: >> >> 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 >> > > > > -- > hls > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
