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!
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
On 7/24/07, Andrew Finkenstadt <[EMAIL PROTECTED]> wrote:
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:
I suppose this is one of those odd cases where sql iteration
please help me:
i am looking for a SQLIte project Templates for Dev C++ or Visual C++ 6
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
Database files will reside in a flash based r/w partition. The /var is
currently mounted on a RAM disk, which should
Or, attach then INSERT-SELECT
On 7/25/07, Mohd Radzi Ibrahim <[EMAIL PROTECTED]> wrote:
How about dumping and import into new db?
- Original Message -
From: "Colin Manning" <[EMAIL PROTECTED]>
Sent: Wednesday, July 25, 2007 7:05 AM
Mail list logo