> I believe other databases handle such a use case as one may expect, but then they have MVCC or lots of other fancy stuff - the cost of which I don't really want in my embedded applications for which sqlite is perfect! No database supports inverleaving updates within a select. The exception, of course, are those database which support *BOTH* "SELECT ... FOR UPDATE ..." and "UPDATE ... WHERE CURRENT OF CURSOR". "Proper support" for this feature is limited to RDBMS systems which were originally designed for "Big Iron" (as in the dinosaur pen) such as DB2 and Oracle. Some other bitty-box RDBMS systems seem to claim to support the syntax, but do not actually support the process. > I believe other databases handle such a use case as one may expect, but then they have MVCC or lots of other fancy stuff - the cost of which I don't really want in my embedded applications for which sqlite is perfect! With respect to "other databases that have lots of other fancy stuff", most notably client/server systems, appearing to support this is "I can understand why you might think that, but I could not possibly comment". However, I will comment. Client/Server databases *appear* to support this because they perform the query in its entirety on the "server" before sending the results back to the "client" for processing. So although it may appear to the lay observer that the "update" is interleaved with the query, in actual fact the update is **not** interleaved with the select execution. Like "scrollable cursors" which are implemented by massive amounts of code contained within the server and the client, SQLite3 does not incorporate the massive amounts of code or the buffering required to "make it appear to the lay observer" that these are actual real things which exist. With SQLite3 you need to write that massive amount of code and buffering yourself.