Now you have made me worry. If cache can only be shared by connections
created in one thread then there is no shared cache. I must investigate
this more closely. Perhaps my reading of the documentation included a
dose of wishful thinking and a belief that "shared" meant shared!
Looking throu
...snip...
http://www.sqlite.org/cvstrac/tktview?tn=2536
I am working on building a test case. The problem remained when I reverted
to 3.3.17 using the identical database files.
On further research, it appears to be related to max_page_count being
exceeded during insertion of a row, leaving behind a primary key reference
in the (primary key) index on the BLOB instead of being cleaned up during
rollback.
On 7/24/07, Andrew Finkenstadt <[EMAIL PROTECTED]> wrote:
Using
Igor,
You were indeed correct the SQL only version when the stack has say 8000 rows
was terrible. It took 20+ seconds in my application.
I re-wrote using a programatic approach, the resulting timing was astounding:
.1 second.
I suppose this is one of those odd cases where sql iteration
Hello
please help me:
i am looking for a SQLIte project Templates for Dev C++ or Visual C++ 6
Thank you
I didn't realise VACUUM could be so memory hungry but that should still be ok
for us because:
My system is an embedded arm9 running an RTOS with a flash file system, so
no disk.
Database files will reside in a flash based r/w partition. The /var is
currently mounted on a RAM disk, which should me
6 matches
Mail list logo
