On 31 Jan 2017, at 3:29am, Jens Alfke <j...@mooseyard.com> wrote: > I’ve discovered (after some debugging) that if I iterate over the the rows in > a table using sqlite3_step, and update each row after it’s returned, Bad > Stuff happens. Specifically, my query is just getting the first row over and > over and over again, and the iteration runs forever
Is your UPDATE command changing a value which is used for the SELECT ? If so, what you reported is expected behaviour. If you’re expecting to execute two statements at the same time you should be using two connections. > I’m unsure what to do now. I am working on a library whose API exposes > iterator objects that run queries; the iterator’s “next()” method internally > calls sqlite3_step. Nope. Cannot do that. Any number of things might happen between the first _step() and the _finalize(). For all you know someone might delete the object the iterator is currently on instead of just updating it. Then where would the iterator be ? How would you know to release the resource ? And once you knew it, how would you do it ? One solution is to make each call to .next() do its own SELECT. So if, for example, it was acceptable to iterate the rows in rowid order then calling .next() would do SELECT rowid FROM MyTable WHERE rowid > [current rowid] ORDER BY rowid LIMIT 1 If this gives a row, that’s your next object. If it doesn’t, you’ve reached the end. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
