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

Reply via email to