Perhaps an analogy will help: Imagine you are given a piano. Pressing keys on the piano will cause the corresponding tones to be played. If you hit the keys on the piano with a hammer, then this too will cause tones to be played; however, it will also most likely cause mechanical failure (i.e. no more tones played) of the piano over time, because it is not designed to be used in that manner. This is no fault of the piano or it's maker, even without a US disclaimer stating that keys on the piano may only be pressed within certain limits.
Likewise, updating the index you are scanning with (including the default rowid index) constitutes breach of design parameters, and not only in SQLite but also in many other indexed storage systems. -----Ursprüngliche Nachricht----- Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im Auftrag von Vermes Mátyás Gesendet: Donnerstag, 09. März 2017 15:43 An: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> Betreff: Re: [sqlite] sqlite3 feature or regression Thanks. Naturally I had experimented with several versions of the program, and saw that any ordering makes the new feature/error disappear. You can see it if you read the comment at the bottom of my original script. But my purpose was the opposite: demonstrate the regression. I am not interested in this thing. I do not have applications based on SQLite. Simply I think that this feature/error cannot be left in its current state, because this is in contradiction with the axiom, that the result of a query must not depend from the existence of an index. I wanted to help you with this bug report, but I cannot do more for that. > As Dan already observed, the problem results because you are modifying > an index in the middle of a scan of that index, thereby messing up the > scan. Don't do that. The safest approach is to run the query to > completion, then go back and start the loop over UPDATEs. > > If you add "ORDER BY +rowid" to the query, that forces the query to > run to completion first and then go through the sorter, before you get > any results back, which solves the problem. -- Vermes Mátyás <vermes.mat...@comfirm.hu> _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___________________________________________ Gunter Hick Software Engineer Scientific Games International GmbH FN 157284 a, HG Wien Klitschgasse 2-4, A-1130 Vienna, Austria Tel: +43 1 80100 0 E-Mail: h...@scigames.at This communication (including any attachments) is intended for the use of the intended recipient(s) only and may contain information that is confidential, privileged or legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Thank you for your cooperation. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
