On Wed, Jun 01, 2011 at 19:23:16 +0100, Simon Slavin wrote:
> On 1 Jun 2011, at 7:12pm, Jan Hudec wrote:
> >> Do not update a table if there is some select statement currently
> >
> > Actually insert, update and delete are OK. Drop and alter table are
> > a problem.
>
> Pavel is right. He left out some details to make things simple.
>
> Suppose you do a SELECT ... WHERE ... that returns ten rows. You retrieve
> three rows, then make a change that would mean you should have retrieved
> eleven rows, not ten. You can't predict what SQLite will do without
> knowing the internal workings of SQLite, right ? So don't do that. The
> same is true even if the only thing you change is values to be returned.
> Does SQLite copy the all values when you execute the SELECT, or row-by-row
> as you step through the results ? Again, you don't know unless you know
> the internal workings of SQLite. So don't do that.
Oh, right. There are actually two distinct problems:
- Inside one transaction, running select may or may not see data inserted or
updated in parallel. For selects on other handles it's however well
defined that they will not read the data and no operations will fail.
- Dropping or modifying table will fail (with "table is locked" status) if
there are any running statements involving that table.
--
Jan 'Bulb' Hudec <b...@ucw.cz>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
