On 2 Jun 2011, at 6:01pm, Jan Hudec wrote: > - Inside one transaction, running select may or may not see data inserted or > updated in parallel.
Sorry to go on about this but you underestimate the problem. Suppose you're part-way through _step()ing through the results of a SELECT and an UPDATE modifies a field in your ORDER BY clause of one row. It could move the row you're currently on, moving it back to the beginning of the sort order. Or it could move it to the end of the sort order. Or it could move a row you haven't got to yet, to a position you've already gone past. When the next _step() moves to the 'next' record it might end up somewhere completely different to where you expected. In all these cases, without knowing undocumented internal details about how that version of SQLite works, you can't predict what will happen. Your SELECT might skip one or more rows: not just a row you modified but other untouched rows. Or it might read some rows twice: not just a row you modified but other untouched rows. Or it might be completely immune to the problem having fetched and stored row indexes somewhere. So don't do that. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
