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
