>> Interleaving the row fetching from a SELECT with concomitant UPDATE involving common tables in both is fraught with peril. >> The proper solution is to not do that. > It would be nice if the sqlite manual said this somewhere, and if it could reliably detect and report API misuse in such cases (when SQLITE_ENABLE_API_ARMOR is set). Everyone does know that since about the very first SQL driven RDBMS system was conceived more than half a century ago. The fact is that half a century ago "special steps" and "language semantics" were introduced to deal with this issue and still exist (in various states of working for varying definitions of working) to this very day (the common case seems to be that the "language semantics" have been more or less maintained but the "working correctly" part has been totally ignored in the Eternal Septemberite drive to Form over Function). It should be noted, however, that this is not just an SQL and RDBMS issue as it has existed for thousands upon thousands of years -- even the Monks indexing their scroll collections had the same problem with concurrent updating of the "index scroll" when the "researcher" was away with his concubine for a couple of weeks. Just because you remember where you were in the "index scroll" does not prevent things from being moved around and added or deleted while you go away and on a dalliance. The only way you can be sure that you have a "stable view" of the "index scroll" is to wait while the Monks make an exclusive copy for your use. When using so-called "navigational databases" everyone and their mother knew that just because you know where "here" is does not mean that you cannot update "before here" and "after here" and that what you do "here and now" affects "the here after". In fact, you probably learned that concept by the time you were 5 years old. Why would you suddenly believe that what you do here and now does not affect the here after when it becomes here now? SQLite3 supports neither the "special steps" nor "langauge semantics" to implement this complicated (non-Lite) process by magic. You must implement this yourself as there is no syntax in SQLite3 that will tell SQLite3 to do it for you. As to reporting misuse, there is no way to know that you are doing something ill-conceived. As a theoretically competent user of a tool, it is your job to use it competently. There is no way for, for example, for a band saw to know that it is cutting off your hand and not just cutting through a particularly dense knot in the wood. And it is documented somewhere as I have seen it even though it is obvious to any casual observer (probably in one of the pages documenting isolation since it is an isolation (or rather, a lack thereof) issue).