Dennis,
My servers main connection itself is in :memory:, but your suggestion
will still work.
However there are two things I don't like about this method. One is that I
need to parse the prepared statments and prefix queries, and replace the
table name with the temp table name in the surrogate query. Two is that if
the client does lots of queries before disconnecting from the server it
can waste whole lot of memory. Three is that it is a hack.
However, server can keep track of client temp tables and drop them after
finalize. Parsing might not be as bad as I think. Right now this seems to be
the only choice.
Thanks,
-Alex
On Tue, Jun 10, 2008 at 4:33 PM, Dennis Cote <[EMAIL PROTECTED]> wrote:
> Alex Katebi wrote:
> > The only ugliness is that select locks the tables. I wish D. Hipp would
> give
> > us an option for pStmt to create a temporary table of the select result
> set
> > and delete that temp table after finalize automatically. This way a
> client
> > can sit on a prepare/step for a long time.
> >
>
> Alex,
>
> Your application can do this by itself without any changes to the SQLite
> core. You can attach a :memory: database as tmp to your main database,
> then prefix your client's query with "create table tmp.result as", and
> then return the result of a surrogate query "select * from tmp.result"
> instead of the actual result of the client's query. This will only hold
> the lock on the main database while the temp table is created, since
> memory database don't use any locking because they are private to a
> single connection. The client can then scan through the surrogate
> results at its leisure. When the client is done you can close the memory
> database.
>
> HTH
> Dennis Cote
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
