I love sqlite3_exec, but I also like prepared statements. Here's a function
I wrote to make it easier to execute prepared statement. I have only tested
with SELECT and INSERT.
Hope someone finds it useful.
-Eric
#include "sqliteInt.h"
#include "os.h"
#include
/*
** Execute SQL code. Return
I'm having a similar problem to this earlier email. I'm a novice linux user,
not easily able to rebuild
the sources.
I have downloaded precompiled tclsqlite-3.5.3.so* from www.sqlite.org as
described in the online doc.
I start tclsh8.4 on fedora core 6, and try to load the tclsqlite library as
de
P Kishor wrote:
On 12/7/07, Igor Tandetnik <[EMAIL PROTECTED]> wrote:
P Kishor <[EMAIL PROTECTED]> wrote:
folks, I have never worked with BLOBs, but am now going to. Feel a
bit nervous.
Here is a question -- what if I have a rather large image and I want
only a certain part of it? Let me give
5.3.tar.gz
cd sqlite-3.5.3
patch -p0 < ../union-alias-20071207.patch.txt
./configure
make
./sqlite3
Please report any issues to the mailing list.
Be a better friend, newshound, and
know
On 12/7/07, Zbigniew Baniewski <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 07, 2007 at 05:49:56PM -0500, Igor Tandetnik wrote:
> > >So I would to ask: are there any benefits from using VARCHAR() and
> > >not TEXT?
> > There is no difference whatsoever to SQLite. It maintains the types for
> > compat
P Kishor <[EMAIL PROTECTED]> wrote:
You are correct. But I don't want to manipulate the image with SQLite
(or any SQL db). I just want to store and retrieve it efficiently.
Storing images as files certainly precludes being able to find just
*that* particular rect and extract it out of a file.
W
On Fri, Dec 07, 2007 at 06:05:35PM -0600, P Kishor wrote:
> don't know about other db, but with the ones I have worked, there is
> no such thing as unlimited text width field. Oracle maxes out VARCHAR
> at 4000 or 8000 (for NVARCHAR)..
Of course, I realize, that "unlimited" is just theory. Perhap
On 12/7/07, Igor Tandetnik <[EMAIL PROTECTED]> wrote:
> P Kishor <[EMAIL PROTECTED]> wrote:
> > folks, I have never worked with BLOBs, but am now going to. Feel a
> > bit nervous.
> >
> > Here is a question -- what if I have a rather large image and I want
> > only a certain part of it? Let me give
On 12/7/07, Zbigniew Baniewski <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 07, 2007 at 05:43:49PM -0600, P Kishor wrote:
>
> > I believe it used to... fixed width (CHAR) was quicker than VARCHAR
> > while the latter was more space efficient, obviously.
>
> But he didn't compare variable, but limited w
P Kishor <[EMAIL PROTECTED]> wrote:
folks, I have never worked with BLOBs, but am now going to. Feel a
bit nervous.
Here is a question -- what if I have a rather large image and I want
only a certain part of it? Let me give an example -- say, I want to
store an image of the entire US, but when I
On Fri, Dec 07, 2007 at 05:43:49PM -0600, P Kishor wrote:
> I believe it used to... fixed width (CHAR) was quicker than VARCHAR
> while the latter was more space efficient, obviously.
But he didn't compare variable, but limited width (VARCHAR()) - with variable
unlimited width fields (TEXT)?
--
folks, I have never worked with BLOBs, but am now going to. Feel a bit nervous.
The way I understand it, our favorite db breaks a BLOB into its
predetermined chunks (4096 bytes or whatever) and figures out how and
where to store them. We just ask it to put in the BLOB or take out the
BLOB, and SQL
On 12/7/07, Zbigniew Baniewski <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 07, 2007 at 05:49:56PM -0500, Igor Tandetnik wrote:
>
> > >So I would to ask: are there any benefits from using VARCHAR() and
> > >not TEXT?
> >
> > There is no difference whatsoever to SQLite. It maintains the types for
> > co
-Original Message-
From: P Kishor [mailto:[EMAIL PROTECTED]
Sent: Friday, December 07, 2007 5:50 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Any advantages of "varchar()" over "text"?
I may be wrong, but my understanding is that other than INTEGER
PRIMARY KEY, SQLite doesn't gi
On Fri, Dec 07, 2007 at 04:50:19PM -0600, P Kishor wrote:
> I may be wrong, but my understanding is that other than INTEGER
> PRIMARY KEY, SQLite doesn't give a rat's batuti about what you define
Perhaps it's related to "closed relations" between SQLite and Tcl. Well,
it's even more comfortable t
On Fri, Dec 07, 2007 at 05:49:56PM -0500, Igor Tandetnik wrote:
> >So I would to ask: are there any benefits from using VARCHAR() and
> >not TEXT?
>
> There is no difference whatsoever to SQLite. It maintains the types for
> compatibility with other DMBS only
Just from curiosity: perhaps could
On 12/7/07, Zbigniew Baniewski <[EMAIL PROTECTED]> wrote:
> We can define in, using SQLite, both "fixed max. width" VARCHAR() fields (I
> know, in practice it can be crossed over), as well as "no limit" TEXT fields.
>
> So I would to ask: are there any benefits from using VARCHAR() and not TEXT?
>
Zbigniew Baniewski wrote:
We can define in, using SQLite, both "fixed max. width" VARCHAR()
fields (I know, in practice it can be crossed over), as well as "no
limit" TEXT fields.
So I would to ask: are there any benefits from using VARCHAR() and
not TEXT?
There is no difference whatsoever to
We can define in, using SQLite, both "fixed max. width" VARCHAR() fields (I
know, in practice it can be crossed over), as well as "no limit" TEXT fields.
So I would to ask: are there any benefits from using VARCHAR() and not TEXT?
For example faster(?) data access - or just anything, that makes es
Mark Riehl wrote:
> All - We're in the process of porting an application that used MySQL
> to an embedded platform running SQLite. Two of the built-in functions
> we used frequently were the functions to create and convert from Unix
> epochs (UNIX_TIMESTAMP(), FROM_UNIXTIME).
>
> Are there any pl
All - We're in the process of porting an application that used MySQL
to an embedded platform running SQLite. Two of the built-in functions
we used frequently were the functions to create and convert from Unix
epochs (UNIX_TIMESTAMP(), FROM_UNIXTIME).
Are there any plans to add this functionality
I believe the optimizations that would help the most is the time spent
on "commits."
Thanks,
Brett
-Original Message-
From: Scott Krig [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 29, 2007 10:57 AM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] Performance tuning using PRAGMA,
Sreedhar.a wrote:
Hi Dennis,
I have created 2 tables for PlayList as u suggested as Follows.
"CREATE TABLE MUSIC (MusicId INTEGER PRIMARY KEY NOT NULL,Album_Id
INTEGER,Artist_Id INTEGER,Bgm_Id INTEGER, Track Text);"
MusicId Album_Id Artist_Id Bgm_Id Track
11
23 matches
Mail list logo
