Re: [sqlite] Testing performance hypothesis of scanning a table with no indexes versus reading same data from a file

> On Mon, 21 Jul 2014 13:05:13 +, Markus Schaber > said: > Hi, > Von: David Canterbrie >> I've been tasked with trying to understand how much of a performance hit one >> would get if one had to scan a table in its entirety versus reading the same >> data stored as a

Re: [sqlite] Sometimes when my process restarts, it returns error "database is locked"

I was able to get the callback working. But I am curious as I am just seeing the same error details as the sqlite3 api itself returns. For e.g. SQLITE_LOG: sqlite errcode=26, sqlite errmsg=file is encrypted or is not a database The same error code I get in the return value of sqlite3_step.

[sqlite] Entry Points missing from sqlite3ext.h

Found in 3.8.4.3.  Missing from sqlite3ext.h are sqlite3_auto_extension() and sqlite3_cancel_auto_extension().  Now, you might ask, why would I need these functions in an extension?  Well, it turns out I'm writing a virtual table that accesses someone else's library that also uses SQLite, at

Re: [sqlite] Variable number of parameters in a prepared statement's IN clause

I would like to +1 the idea about virtual talbe. Using variable number of '?'s is never the option. You must know that there is limit to how many '?'s can be there. One day this approach will stab you in the back. The very day when you will need to bind more elements than limit value. > >

Re: [sqlite] Variable number of parameters in a prepared statement's IN clause

I would like to +1 the idea about virtual talbe. Using variable number of '?'s is never the option. You must know that there is limit to how many '?'s can be there. One day this approach will stab you in the back. The very day when you will need to bind more elements than limit value. > >Is it

Re: [sqlite] new support for virtual tables written in Perl

Hi Laurent, > This is to announce that next version of DBD::SQLite (the Perl > driver for accessing SQLite databases) will include support for > virtual tables written in Perl. Thanks for the effort you put into this. I'm glad to see DBD::SQLite continuing to improve, although I already consider

[sqlite] new support for virtual tables written in Perl

Hi, This is to announce that next version of DBD::SQLite (the Perl driver for accessing SQLite databases) will include support for virtual tables written in Perl. This is easier than writing virtual table extensions in C code, so I hope to see creative uses of this feature from fellow Perl

Re: [sqlite] Testing performance hypothesis of scanning a table with no indexes versus reading same data from a file

Hi, Von: David Canterbrie > I've been tasked with trying to understand how much of a performance hit one > would get if one had to scan a table in its entirety versus reading the same > data stored as a new-line (or some sort like that) from a file. > > The hypothesis I suppose we're trying to

[sqlite] tcl test suite 'veryquick' reports errors using modified compile time options

I am using SQLite version 3.7.17 with modified compile time options. Therefore it is suggested to run the test suite in order to prove the reliability of the resulting database. Compiling SQLite as follows without modified options the tcl test suite 'veryquick' is running successfully: