Michael Roth wrote:
> Exists the same error in the sqlite3_prepare call? Anybody validated
> this?
I just tested this with SQLite V3.0 and it does not display this quirk. I
get the same performance using a statement that is prepared inside a
transaction and one that is prepared outside a transacti
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Smith wrote:
| This has come up on the list before, and should probably be documented on
| the Wiki in http://www.sqlite.org/cvstrac/wiki?p=PrecompiledSql.
[...]
| As the sqlite3_compile API is still experimental (the SQLite V3 API
| reference
: "Dennis Cote" <[EMAIL PROTECTED]>
_To: "sql-users" <[EMAIL PROTECTED]>
_Date: Wed, 4 Aug 2004 12:25:36 -0600
_Subject: [sqlite] precompiled SQL and transactions
NOTE: DO NOT REPLY TO THIS MESSAGE, IT WILL BE AUTOMATICALLY REDIRECTED TO TRASH.
(Non risp
This has come up on the list before, and should probably be documented on
the Wiki in http://www.sqlite.org/cvstrac/wiki?p=PrecompiledSql.
As to whether it's a problem, I think probably not as the 'fix' is so
trivial. If you want to fix, then simply wrap the begin/compile/commit in
a new function
Hi All,
I have discovered a quirk in the SQLite API (both 2.8 and 3.0) when using
precompiled SQL statements with transactions.
My goal was to perform a series of inserts into a database as quickly as
possible. To this end I first used a single explicit transaction around the
series of inserts. S
Hi All,
I have discovered a quirk in the SQLite API (both 2.8 and 3.0) when using
precompiled SQL statements with transactions.
My goal was to perform a series of inserts into a database as quickly as
possible. To this end I first used a single explicit transaction around the
series of inserts. S
6 matches
Mail list logo
