Branko Čibej <br...@e-reka.si> writes: > On 15.03.2011 15:34, Philip Martin wrote: >> So with the temporary table approach the callback really has to use a >> separate database connection to read/write the database from within the >> callback. >> >> However I think that is also the case if we were to avoid the table and >> simply lock the main database; if just one connection was reused it >> might be attempt to reuse an SQLite statement. > > There's a trick we could use if that's a problem, namely: instead of > simply creating temporary tables by using the connection's default temp > database; create another temp *database* per query. It's anonymous, so > only the code that holds its handle knows about it, and there's no way > for the callback to access it. > > This would require a bit more code, however, the concept is a reusable > pattern (and the code for the temp database handling would be reusable, > too.)
Sounds plausible. Is it valid for an application to call proplist and then in the callback call proplist again, say on a different part of the working copy? To support it I think we need to avoid using a fixed name for the temporary database, perhaps we could use a sequence number in the database connection structure? I thought we would have this problem with the name of the temporary table, but we get a database locked error first. -- Philip
