Thank you for your advice Simon and Keith.
We strive to make the migration process faster, because our technicians
are responsible of changing the program version of each embedded device
and then migrating its database, not the end user.
I'm creating the indexes last as you said, but
On 12 Jun 2017, at 4:20pm, Simon Slavin wrote:
> Please add the ANALYZE command after your existing VACUUM.
Before. Not after. Do ANALYZE, then VACUUM. It might make no difference but
technically it may yield a faster result. Or a smaller file. Something good.
>
On Monday, 12 June, 2017 08:53, Венцислав Русев wrote:
> I am using sqlite C API to migrate a database. Migration consists of
> many SQL statements that are known in advance.
> To migrate a DB from version 3 to version 7 the C program does the
> following:
> 1.
On 12 Jun 2017, at 3:53pm, Венцислав Русев wrote:
> To migrate a DB from version 3 to version 7 the C program does the following:
This migration is a one-time process, right ? Each customer has to do it only
once, then never again. It not like they have to wait through
"many (sometimes several thousand) statments" sounds like it could be heavy on
memory requirements.
Are you inserting one row per statement or all rows in one statement? The
latter would be really hard on memory because SQLite will have to parse the
whole statement and generate a gigantic SQL
Hello,
I am using sqlite C API to migrate a database. Migration consists of
many SQL statements that are known in advance.
To migrate a DB from version 3 to version 7 the C program does the
following:
1. disable foreign_keys (PRAGMA foreign_keys = OFF);
2. open transaction (BEGIN
6 matches
Mail list logo