Hi Tim,
>I am also somewhat in the dark about concurrency issues (if any) in a >webservice scenario: > -- Do TEMP tables have database-connection-scope so that there is no >need to name the TEMP table uniquely? Does the table get deleted >automatically when the connection is closed if the client-app neglected >to DROP it? > My webservice establishes a new connection to the database before >each query and immediately closes the connection after the results are >returned. > >Maintenance: > Is the space occupied by a temp table reclaimed automatically when it >is dropped? Or does the use of TEMP tables require periodic maintenance >using VACUUM? Why don't you use a :memory: database for this? I'm doing this in some applications and it works very well with little fuss. I open my main (disk-based) base(s) and also create a :memory: one which I attach to the main. Now I can use it at will. As has been discussed here recently, you can't have FK with parents/children in separate bases, or other types of split constraints/triggers. Using an intermediate table like this also gives you more freedom for fancy behavior that would be much more difficult or even impossible to achieve using only SQL and the main base only (without a temp table). I mean indexing and/or ordering (possibly with complex index/collation) your memory table so that a match occurs with best speed, a trigger to record which word did the client match in the list, a.s.o. You can create separate tables having unique name or put some randomized client transaction_id in a unique table... Simply drop the table as soon as you (or your client) don't need it anymore. Cheers, _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users