On 2/18/06, SanjayK <[EMAIL PROTECTED]> wrote:
>
>
> I am using a virtual tree control to display columns dynamically when
> needed
> from the sqlite database. While it works ok for display purposes, in
> certain
> other operations, I need to improve the speed. I found that the new sqlite
> random
Hello.
I am trying to wrap C++ class over sqlite API.
The idea is to keep sqlite3* into smart pointer.
Unfortunately sqlite3_open function does not guarantee strong error safety.
One needs call sqlite3_close even if sqlite3_open has failed.
While exploring sqlite documentation and sources I have
I am using a virtual tree control to display columns dynamically when needed
from the sqlite database. While it works ok for display purposes, in certain
other operations, I need to improve the speed. I found that the new sqlite
random access (even with prepared/transaction) approach is about 15
On Thu, Feb 16, 2006 at 08:23:43PM +0100, Philipp Kn?sel wrote:
> SanjayK schrieb:
> >Since SQLite is perfect for use in single-user desktop utility applications
> >and since such applications typically store hierarchial data (tree) in a
> >single table, it would be nice to have support for
[EMAIL PROTECTED] ha scritto:
Among the things that can cause a statement to go stale:
* Any schema change - including a schema change that is caused
by some outside process.
I want to point out that also a VACUUM command can cause a schema change.
AFAIK, an autovacuum operation
Teg <[EMAIL PROTECTED]> wrote:
> Hello drh,
>
> I always assume the prepared statement were transitory. I typically
> create them in a function, use them than delete them. Is there a
> discussion of their life span somewhere? I typically have DB's that
> never change schema after their initial
On 2/18/06, Teg <[EMAIL PROTECTED]> wrote:
>
>
> I always assume the prepared statement were transitory. I typically
> create them in a function, use them than delete them. Is there a
> discussion of their life span somewhere? I typically have DB's that
> never change schema after their initial
Hello drh,
I always assume the prepared statement were transitory. I typically
create them in a function, use them than delete them. Is there a
discussion of their life span somewhere? I typically have DB's that
never change schema after their initial creation. How reliable is it
to say, create
SanjayK <[EMAIL PROTECTED]> wrote:
> I am puzzled as to why the prepared
> statements should be affected if an unrelated new table is created.
>
SQLite has no way of knowing that the table you created, modified,
or dropped does not effect existing prepared statement - no way
that is other than
Hello,
in response to a problem report concerning the sqlite3 egg and SQLite3.3.4
some larger changes have been made to the egg for CHICKEN:
- The bindings now handle "valid" NULL statements correctly, which
allows the execution of statements involving a IF [NOT] EXISTS clause
SanjayK wrote:
It was indeed a problem related to prepared statements. It turned out to be
less work than I imagined. Just before creating the new table, I finalize
all the prepared statements by calling a methd and after creating, I prepare
them again. This solved the problem. But I am puzzled
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jose Da Silva wrote:
> Hi sqlite list,
> By default, linux gcc does not appear to remove information and
> therefore final binaries tend to be larger than they need to be if you
> use stable versions of compiled binaries. [...]
> If the sqlite
Hi sqlite list,
By default, linux gcc does not appear to remove information and
therefore final binaries tend to be larger than they need to be if you
use stable versions of compiled binaries. Many people don't tend to
realize this and therefore compile files larger than necessary if their
13 matches
Mail list logo
