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 haven't
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.
> This can noticeably spee
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. disable foreign_keys (PRAGMA
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 it every day.
You cou
ormance of sqlite3_exec() or maybe
change it to prepare+step?
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_ke
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 TRANSACTI
6 matches
Mail list logo