Alex Katebi <[EMAIL PROTECTED]> wrote: > So are you telling me that if a statement has started a select on a > table with a delayed finalize another statement can update the same > table?
Yes, as of recent enough SQLite version. I'm kind of skeptical myself, but Dr. Hipp insists this is possible and safe. I haven't personally worked up the courage to use this feature though. I do update one table while scrolling through another - that works. > The reason I ask this question is that in my application a user can > start > a query and take his time before he ends it. Meanwhile the same table > needs > to be updated by my application. Can you tell be why there would be > no lock > contention? There is a lock (not the file-level database lock, but the OS mutex) during the call to sqlite3_step. But other than that, there's no contention. In other words, your update statement may have to wait while the select retrieves the next row, but it won't have to wait until you retrieve the complete recordset. Of course, there is no transaction isolation between the two statements, you are in dirty read mode. E.g., sufficiently complex SQL statemets may need to read the same row of the same table more than once: it is possible that one such read would see the original data and the other modified data. The recordset thus produced might be, shall we say, interesting. Igor Tandetnik _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
