RE: [sqlite] Low Level API for SQLite3

2006-05-10 Thread Anish Enos Mathew

Dennis,
   Thank you so much for sending me the code. Its works fine!! It
took 8 sec to insert 10 records into the table where previously it
was taking 30 sec to insert 1 records. Dennis, if u could do me a
favour, can u explain me how to retrieve datas from the table. Or if u
have the code for that, can u pls send it to me...

-Original Message-
From: Dennis Cote [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 09, 2006 9:33 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Low Level API for SQLite3

Anish Enos Mathew wrote:
 Thank you so much cote, for ur valuable suggestion. I would be greatly
 thankful to u if u could send me a simple c program which uses the
above
 API's to insert some values into the SQLite database.
  
  
Anish,

The sample program below shows how to use precompiled inserts in
SQLite.  On my computer I get the following  results for 1,000,000
inserts. This produces a database file that is 46.9 MB.

  Executed 100 inserts in 11 seconds, 90909 inserts/sec

For comparison I made a second program that builds equivalent SQL
statements and then passes them to SQLite to compile and execute using
sqlite3_exec().

  Executed 100 inserts in 34 seconds, 29412 inserts/sec

This program takes 3 times longer to execute, so it is spending 2/3 of
its time generating and parsing the SQL statements.

Note that surrounding the insert loop with a begin transaction/commit

transaction pair is extremely important to getting these high insert
rates. Without a transaction these programs are both much slower since
they become I/O bound. They both take about 50 seconds to do 500 inserts

at about 10 inserts/sec. This is slower by a factor of about 3000 or
9000.

HTH
Dennis Cote

P.S. I apologize if Anish is not your first name, but I believe that
most people use the normal spoken order of their names for when setting
up an email account.



Prepared insert statements.

#include stdio.h
#include stdlib.h
#include time.h

#include sqlite3.h

// struct for sample records.
typedef struct {
int a;
float   b;
charc[50];
} record;

// error checking elimnated for clarity
int main(int argc, char *argv[])
{
char *database = test.db;
sqlite3 *db;
sqlite3_stmt *insert;
record sample;
int samples = 100;
int i;
time_t bgn, end;
double t;

// open a new database (after deleting any previous database)
remove(database);
sqlite3_open(database, db);

// create a table
sqlite3_exec(db, create table t (a integer, b float, c text),
NULL, NULL, NULL);

// open transaction to speed inserts
sqlite3_exec(db, begin transaction, NULL, NULL, NULL);

// compile an SQL insert statement
sqlite3_prepare(db, insert into t values (?, ?, ?), -1, insert,
NULL);

// records start time
bgn = time(NULL);

// loop to insert sample values
for (i = 0; i  samples; i++) {
// generate the next sample values
sample.a = i;
sample.b = i * 1.1;
sprintf(sample.c, sample %d %f, sample.a, sample.b );

// bind parameter values
sqlite3_bind_int(insert, 1, sample.a);
sqlite3_bind_double(insert, 2, sample.b);
sqlite3_bind_text(insert, 3, sample.c, -1, SQLITE_STATIC);

// execute the insert
sqlite3_step(insert);

// reset for next loop
sqlite3_reset(insert);
} 

// record end time
end = time(NULL);

// finalize compiled statement to free memory
sqlite3_finalize(insert);

// close transaction
sqlite3_exec(db, commit transaction, NULL, NULL, NULL);

// close the database
sqlite3_close(db);

// report timing
t = difftime(end, bgn);
printf(Executed %d inserts in %.0f seconds, %.0f inserts/sec\n,
samples, t, samples / t);
return 0;
}



Compiled insert statements.

#include stdio.h
#include stdlib.h
#include time.h

#include sqlite3.h

// struct for sample records.
typedef struct {
int a;
float   b;
charc[50];
} record;

// error checking elimnated for clarity
int main(int argc, char *argv[])
{
char *database = test.db;
sqlite3 *db;
char insert[200];
record sample;
int samples = 100;
int i;
time_t bgn, end;
double t;

// open a new database (after deleting any previous database)
remove(database);
sqlite3_open(database, db);

// create a table
sqlite3_exec(db, create table t (a integer, b float, c text),
NULL, NULL, NULL);

// open transaction to speed inserts
sqlite3_exec(db, begin transaction, NULL, NULL, NULL);

// records start time
bgn = time(NULL);

// loop to insert sample values
for (i = 0; i  samples; i++) {
// generate the next sample values
sample.a = i;
sample.b = i * 1.1;
sprintf(sample.c, sample %d %f, sample.a, sample.b );

// build next insert statement
sprintf(insert, insert into t values (%d, %#f, '%s'),
sample.a, sample.b

Re: [sqlite] Low Level API for SQLite3

2006-05-10 Thread Nathan Kurz
On Thu, May 11, 2006 at 10:20:26AM +0530, Anish Enos Mathew wrote:
 
 Dennis,
Thank you so much for sending me the code. Its works fine!! It
 took 8 sec to insert 10 records into the table where previously it
 was taking 30 sec to insert 1 records. Dennis, if u could do me a
 favour, can u explain me how to retrieve datas from the table. Or if u
 have the code for that, can u pls send it to me...
 

Anish,

Dennis has provided you with lots of help.  At a certain point (which
he may or may not have reached) he will want to stop providing this
help.  This is OK, but unfortunately he may also decide to stop
providing help to other people, like me.  This would be bad.  

I think it may be the time for you to do more research, try things
out, and then come back when you have more specific questions.  This
is of course only my personal opinion.  Here's a link that expresses
this more tactfully than I can: http://www.slash7.com/pages/vampires

Nathan Kurz
[EMAIL PROTECTED]




Re: [sqlite] Low Level API for SQLite3

2006-05-09 Thread Ralf Junker
Is there more information available on saving and loading prepared statements 
and omitting the parser from the library?

Thanks  Regards,

Ralf

the parser can be completely omitted from the SQLite library,
reducing the library footprint to as small as 60KiB.
That can be very helpful for embedded devices with
extremely tight memory and processor constraints.  The
calls to sqlite3_prepare() can occur on the development
workstation and the low-power embedded processor only
has to invoike sqlite3_bind(), sqlite3_step() and
sqlite3_reset().  This approach requires a proprietary 
add-on, however.



Re: [sqlite] Low Level API for SQLite3

2006-05-09 Thread drh
Ralf Junker [EMAIL PROTECTED] wrote:
 Is there more information available on saving and loading prepared statements 
 and omitting the parser from the library?
 

OVERVIEW

The SQLite Stored Statement Extension consists of twelve
source code files that are added to a standard public-domain SQLite
release.  The added files are proprietary and are used under license.
But the bulk of the code is from SQLite which continues in the public
domain.

The Stored Statement Extension (hereafter called SSE) provides the
programmer with two new APIs:

   int sqlite3_serialize(sqlite3_stmt*, void**, int*);
   int sqlite3_deserialize(sqlite3*, void*, int, sqlite3_stmt**);

The first routine takes an SQL statement that was generated by
sqlite3_prepare() and converts it into a form that can be stored
on disk or compiled into a program.  The second routine does the
reverse; it takes the serialization of a statement and converts it
back into a working SQL statement that can be used just like any
other statement created by sqlite3_prepare().

In addition to the new APIs, the SSE comes with instructions and
example Makefiles that allow the developer to compile SQLite so
that the parser and code generator are omitted.  Such a build will
typically be much smaller than a standard SQLite build - less than
half size of a standard SQLite build.  The sqlite3_prepare()
API will be unavailable in a build of SQLite that omits the parser,
so the sqlite3_deserialize() API must be used instead.

The point of the SSE is to allow manufacturers of low-power
embedded devices to make use of the SQLite backend without having
to host the SQL parser and code generator on the device.  The
parser and code generator are on a developers desktop where
they generate serialized SQL statements which are then loaded
into the embedded device and executed by the backend.  This
provides the developer with the full power of a transactional
SQL database engine but with a much smaller code footprint.

MEMORY AND DISK USAGE

The size of the SQLite library without the parser component will be
between 65 and 90KiB depending on what features are included in the
build.  (Example:  The built-in date/time functions, if included, add
about 8KiB to the library footprint.)  An additional 50 to 100KiB of
stack and heap space are require to run common queries.  More heap
space may be required for complex queries.  There is often a trade-off
between memory utilization and performance;  the database will
typically run faster if more heap memory is available.

The size of a serialized statement is typically about 5 times the size
of the original SQL text, though this ratio can vary significantly
depending on the database schema.  For example, the serialization of
SELECT * FROM table1 will be much larger if table1 contains 100
columns than if it contains only 1 column.  In one typical application,
the size of 81 serialized statements ranged from 25 to 1000 bytes
with an average size of 275 bytes.  We expect other applications to
show similar results.  These figures assume that the  binary encoding
for serialized statements is selected.  When an ASCII text encoding is
used, the sizes grow by about 25%.

LIMITATIONS

There are limitations to this approach.  Compiled statements in
SQLite depend heavily on details of how specific tables are arranged
in the database file.  Those details change whenever the database
schema changes (due to a CREATE or DROP or ALTER statement) or when
the VACUUM command is run.  Thus, statements that have been created
using sqlite3_serialize() will only work on a database that has
not been modified by CREATE, DROP, ALTER TABLE, or VACUUM since
the statement was created.  If new tables or indices are added
to a database or if the database is vacuumed, then all statements
must be recompiled.

The sqlite3_serialize() routine must be used on a freshly compiled
statement.  sqlite3_serialize() will not work after a statement
has been passed to sqlite3_step().

The exact same version of SQLite must be used to serialize and
deserialize statements.  It will not work to serialize statements
from one version of SQLite and then attempt to deserialize and
run them using a different version.

The sqlite3_deserialize() routine does little to no error checking
of its input.  If the input is malformed, the result could be a
serious software malfunction such as a segmentation fault, an
infinite loop, or database corruption.  Developers should take care
to verify that input to sqlite3_deserialize() is exactly the same
as the output from a prior sqlite3_serialize().

ADDITIONAL FEATURES

The sqlite3_serialize() routine can generate either a binary or
an ASCII text serialization of a statement.  This choice must be
made at compile-time.   The default is to use a binary encoding.
If the -DSQLITE_SSE_ASCII option is added to the compiler command-
line then an ASCII encoding is used.  The advantage of an ASCII text
serialization is that it is easier to insert into a compiled 

Re: [sqlite] Low Level API for SQLite3

2006-05-09 Thread Dennis Cote

Anish Enos Mathew wrote:

Thank you so much cote, for ur valuable suggestion. I would be greatly
thankful to u if u could send me a simple c program which uses the above
API's to insert some values into the SQLite database.
  
  

Anish,

The sample program below shows how to use precompiled inserts in 
SQLite.  On my computer I get the following  results for 1,000,000 
inserts. This produces a database file that is 46.9 MB.


 Executed 100 inserts in 11 seconds, 90909 inserts/sec

For comparison I made a second program that builds equivalent SQL 
statements and then passes them to SQLite to compile and execute using 
sqlite3_exec().


 Executed 100 inserts in 34 seconds, 29412 inserts/sec

This program takes 3 times longer to execute, so it is spending 2/3 of 
its time generating and parsing the SQL statements.


Note that surrounding the insert loop with a begin transaction/commit 
transaction pair is extremely important to getting these high insert 
rates. Without a transaction these programs are both much slower since 
they become I/O bound. They both take about 50 seconds to do 500 inserts 
at about 10 inserts/sec. This is slower by a factor of about 3000 or 9000.


HTH
Dennis Cote

P.S. I apologize if Anish is not your first name, but I believe that 
most people use the normal spoken order of their names for when setting 
up an email account.




Prepared insert statements.

#include stdio.h
#include stdlib.h
#include time.h

#include sqlite3.h

// struct for sample records.
typedef struct {
   int a;
   float   b;
   charc[50];
} record;

// error checking elimnated for clarity
int main(int argc, char *argv[])
{
   char *database = test.db;
   sqlite3 *db;
   sqlite3_stmt *insert;
   record sample;
   int samples = 100;
   int i;
   time_t bgn, end;
   double t;

   // open a new database (after deleting any previous database)
   remove(database);
   sqlite3_open(database, db);

   // create a table
   sqlite3_exec(db, create table t (a integer, b float, c text), 
NULL, NULL, NULL);


   // open transaction to speed inserts
   sqlite3_exec(db, begin transaction, NULL, NULL, NULL);

   // compile an SQL insert statement
   sqlite3_prepare(db, insert into t values (?, ?, ?), -1, insert, 
NULL);


   // records start time
   bgn = time(NULL);

   // loop to insert sample values
   for (i = 0; i  samples; i++) {
   // generate the next sample values
   sample.a = i;
   sample.b = i * 1.1;
   sprintf(sample.c, sample %d %f, sample.a, sample.b );

   // bind parameter values
   sqlite3_bind_int(insert, 1, sample.a);
   sqlite3_bind_double(insert, 2, sample.b);
   sqlite3_bind_text(insert, 3, sample.c, -1, SQLITE_STATIC);

   // execute the insert
   sqlite3_step(insert);

   // reset for next loop
   sqlite3_reset(insert);
   }  


   // record end time
   end = time(NULL);

   // finalize compiled statement to free memory
   sqlite3_finalize(insert);

   // close transaction
   sqlite3_exec(db, commit transaction, NULL, NULL, NULL);

   // close the database
   sqlite3_close(db);

   // report timing
   t = difftime(end, bgn);
   printf(Executed %d inserts in %.0f seconds, %.0f inserts/sec\n, 
samples, t, samples / t);

   return 0;
}



Compiled insert statements.

#include stdio.h
#include stdlib.h
#include time.h

#include sqlite3.h

// struct for sample records.
typedef struct {
   int a;
   float   b;
   charc[50];
} record;

// error checking elimnated for clarity
int main(int argc, char *argv[])
{
   char *database = test.db;
   sqlite3 *db;
   char insert[200];
   record sample;
   int samples = 100;
   int i;
   time_t bgn, end;
   double t;

   // open a new database (after deleting any previous database)
   remove(database);
   sqlite3_open(database, db);

   // create a table
   sqlite3_exec(db, create table t (a integer, b float, c text), 
NULL, NULL, NULL);


   // open transaction to speed inserts
   sqlite3_exec(db, begin transaction, NULL, NULL, NULL);

   // records start time
   bgn = time(NULL);

   // loop to insert sample values
   for (i = 0; i  samples; i++) {
   // generate the next sample values
   sample.a = i;
   sample.b = i * 1.1;
   sprintf(sample.c, sample %d %f, sample.a, sample.b );

   // build next insert statement
   sprintf(insert, insert into t values (%d, %#f, '%s'), 
sample.a, sample.b, sample.c);
  
   // execute the insert

   sqlite3_exec(db, insert, NULL, NULL, NULL);
   }  


   // record end time
   end = time(NULL);

   // close transaction
   sqlite3_exec(db, commit transaction, NULL, NULL, NULL);

   // close the database
   sqlite3_close(db);

   // report timing
   t = difftime(end, bgn);
   printf(Executed %d inserts in %.0f seconds, %.0f inserts/sec\n, 
samples, t, samples / t);

   return 0;
}



Re: [sqlite] Low Level API for SQLite3

2006-05-08 Thread Bill KING
Anish Enos Mathew wrote:
 Well, currently I am  doing a mobile project and we are testing the
 performance of four databases depending on the time it takes to insert
 or delete or search a particular data from the database. I am using
 sqlite3 database. I am using sqlite_exec command for doing a particular
 process in the data base. But the problem with sqlite_exec is that the
 sqlite engine should parse the select or insert statement and then
 produces the result. If we are having a low level API for doing the same
 which doesn't takes parsing time, we could directly do the process
 rather than giving the select or insert statements. So I would like to
 know is there any other method which can be used to retrieve or insert
 data's from the database other than using the select or insert commands.
   
Much better, as far as I know (which isn't much). The sql parser
generates vdbe bytecodes (see the explain command), which it then
executes to execute the query as such. You could take a squiz in that
direction.

-- 
Bill King, Software Engineer
Trolltech, Brisbane Technology Park
26 Brandl St, Eight Mile Plains, 
QLD, Australia, 4113
Tel + 61 7 3219 9906 (x137)
Fax + 61 7 3219 9938
mobile: 0423 532 733



Re: [sqlite] Low Level API for SQLite3

2006-05-08 Thread Adrian Ho
On Mon, May 08, 2006 at 04:06:33PM +1000, Bill KING wrote:
 Anish Enos Mathew wrote:
  Well, currently I am  doing a mobile project and we are testing the
  performance of four databases depending on the time it takes to insert
  or delete or search a particular data from the database. I am using
  sqlite3 database. I am using sqlite_exec command for doing a particular
  process in the data base. But the problem with sqlite_exec is that the
  sqlite engine should parse the select or insert statement and then
  produces the result. If we are having a low level API for doing the same
  which doesn't takes parsing time, we could directly do the process
  rather than giving the select or insert statements. So I would like to
  know is there any other method which can be used to retrieve or insert
  data's from the database other than using the select or insert commands.

 Much better, as far as I know (which isn't much). The sql parser
 generates vdbe bytecodes (see the explain command), which it then
 executes to execute the query as such. You could take a squiz in that
 direction.

Fair warning though: I'm pretty sure it's not a blessed interface, and
can therefore subject change without advance notice (it did, after all,
change significantly in the jump to 3.0).

Anish, if your app is just executing one of a number of predetermined
SQL queries, you may want to use sqlite3_prepare() instead, so that you
pay the parsing cost just a few times rather than on every query, while
retaining the flexibility and general clarity of SQL in your program.

- Adrian


Re: [sqlite] Low Level API for SQLite3

2006-05-08 Thread drh
Anish Enos Mathew [EMAIL PROTECTED] wrote:
 Well, currently I am  doing a mobile project and we are testing the
 performance of four databases depending on the time it takes to insert
 or delete or search a particular data from the database. I am using
 sqlite3 database. I am using sqlite_exec command for doing a particular
 process in the data base. But the problem with sqlite_exec is that the
 sqlite engine should parse the select or insert statement and then
 produces the result. If we are having a low level API for doing the same
 which doesn't takes parsing time, we could directly do the process
 rather than giving the select or insert statements. So I would like to
 know is there any other method which can be used to retrieve or insert
 data's from the database other than using the select or insert commands.
 

You can access the database unpublished low-level
APIs, but this is labor intensive, exceedingly error 
prone, and very likely to break in one SQLite release 
to the next.  This approach is definitely not recommended.

A better method would be to call sqlite3_prepare() on
parameterized SQL statements at application startup.
Then use sqlite3_bind_*() to bind parameters to the
various SQL statements, call sqlite3_step() to run them,
then sqlite3_reset() to ready them for another run.
This completely bypasses the parser, except for the
handful of calls to sqlite3_prepare() that occur when
the program is launched.

Note however, that if your database schema changes,
or if you call VACUUM or ATTACH, then you will have to
rerun all of your sqlite3_prepare() statements afterwards.

If you never change your database schema and you never
call VACUUM or ATTACH, then you can compile your SQL
statements in advance (at application build time) and
never invoke the parser at all.  In this scenario, the
parser can be completely omitted from the SQLite library,
reducing the library footprint to as small as 60KiB.
That can be very helpful for embedded devices with
extremely tight memory and processor constraints.  The
calls to sqlite3_prepare() can occur on the development
workstation and the low-power embedded processor only
has to invoike sqlite3_bind(), sqlite3_step() and
sqlite3_reset().  This approach requires a proprietary 
add-on, however.

One final note:  If you are comparing INSERT performance,
be sure to do your SQLite INSERTs from within a transaction.
SQLite typically does about 5 to 10 INSERTs per
second (on a workstation) but only about 60 transactions
per second due to disk rotational latency.  Many people
Try to do a series of raw INSERTs using SQLite, see that
only about 60/second occur, and assume that INSERTs are
slow.  This is not the case.  It is the implied COMMIT
that occurs after each INSERT that is slow.  If you do
a BEGIN, followed by thousands of INSERTs, then a single
COMMIT, things will go much, much faster - literally
thousands of times faster.
--
D. Richard Hipp   [EMAIL PROTECTED]



RE: [sqlite] Low Level API for SQLite3

2006-05-08 Thread Anish Enos Mathew

Thank you so much cote, for ur valuable suggestion. I would be greatly
thankful to u if u could send me a simple c program which uses the above
API's to insert some values into the SQLite database.

-Original Message-
From: Dennis Cote [mailto:[EMAIL PROTECTED]
Sent: Monday, May 08, 2006 8:28 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Low Level API for SQLite3

Anish Enos Mathew wrote:
 I am using sqlite_exec command for doing a particular
 process in the data base. But the problem with sqlite_exec is that the
 sqlite engine should parse the select or insert statement and then
 produces the result.
Anish,

You should definitely look at the sqlite pre-compiled query mechanism.
It uses the following set of API functions to allow very fast repeated
execution of SQL statements by eliminating the SQL compilation process
for all but the first execution.

  sqlite3_prepare()
  sqlite3_bind_*()
  sqlite3_step()
  sqlite3_reset()
  sqlite3_column_*()
  sqlite3_finalize()

You are doing inserts into a table, so you would prepare an SQL insert
command with parameters for the values to be inserted. For example if
you have a table as shown below.

  create table t (
id   integer primary key,
atext,
binteger
  );

You would prepare the following insert statement once using
sqlite3_prepare(). The ? characters are placeholders for parameter
values.

  insert into t values (?, ?, ?);

This will parse the SQL once and give you a compiled SQL statement that
you can execute many times with different values bound to the
parameters, without ever parsing anymore SQL. The prepared statement
only works for the specified table. If you have multiple tables, you
will need to prepare multiple statements, one per table. These prepared
statements can be kept and reused or the duration of your program
(assuming the schema isn't changing).

For each execution you issue a series of sqlite3_bind_*() calls to
supply the values to be used for the parameters, and the call
sqlite3_step() to execute the insert. Finally you will call
sqlite3_reset() to reset the statement so that it is ready to be
executed again. When you have no further need for the prepared statement

you call sqlite3_finalize() to release the memory held by statement.

The same mechanism can be used to prepare and execute SQL queries as
well. After the query is parsed, you bind the parameters that specify
the lookup conditions, and execute the query. The sqlite3_step()
function will return after each result row is located. You then use the
sqlite3_column_*() functions to read the values of the selected columns
for that row, and then call sqlite3_step() again to get the next row.

This mechanism practically eliminates the cost of parsing SQL
statements. If this doesn't meet your needs, than you should probably
look at a different database library since SQLite doesn't have a stable
published API for its b-tree layer. There are many other b-tree packages

that would be a better fit than SQLite if that is the level at which you

need to access your data.
  
Dennis Cote

**

The information contained in, or attached to, this e-mail, contains 
confidential information and is intended solely for the use of the individual 
or entity to whom they are addressed and is subject to legal privilege. If you 
have received this e-mail in error you should notify the sender immediately by 
reply e-mail, delete the message from your system and notify your system 
manager. Please do not copy it for any purpose, or disclose its contents to any 
other person. The views or opinions presented in this e-mail are solely those 
of the author and do not necessarily represent those of the company. The 
recipient should check this e-mail and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused, directly or 
indirectly, by any virus transmitted in this email




Re: [sqlite] Low Level API for SQLite3

2006-05-07 Thread Bill KING
Anish Enos Mathew wrote:
 Any body know whether there are any low level  C API's for sqlite3 ?


 **

 The information contained in, or attached to, this e-mail, contains 
 confidential information and is intended solely for the use of the individual 
 or entity to whom they are addressed and is subject to legal privilege. If 
 you have received this e-mail in error you should notify the sender 
 immediately by reply e-mail, delete the message from your system and notify 
 your system manager. Please do not copy it for any purpose, or disclose its 
 contents to any other person. The views or opinions presented in this e-mail 
 are solely those of the author and do not necessarily represent those of the 
 company. The recipient should check this e-mail and any attachments for the 
 presence of viruses. The company accepts no liability for any damage caused, 
 directly or indirectly, by any virus transmitted in this email

 
   
* notices some of the questions over the last few days and asks if
anybody actually reads the website any more?

-- 
Bill King, Software Engineer
Trolltech, Brisbane Technology Park
26 Brandl St, Eight Mile Plains, 
QLD, Australia, 4113
Tel + 61 7 3219 9906 (x137)
Fax + 61 7 3219 9938
mobile: 0423 532 733



RE: [sqlite] Low Level API for SQLite3

2006-05-07 Thread Anish Enos Mathew

Ya, I know about the API's given in sqlite.org. but that does not
contribute much to my reqirements. I want low level API's so that we can
reduce the  parsing time taken by the sqlite parser.

-Original Message-
From: Lindsay [mailto:[EMAIL PROTECTED]
Sent: Monday, May 08, 2006 10:25 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Low Level API for SQLite3

Anish Enos Mathew wrote:
 Any body know whether there are any low level  C API's for sqlite3 ?
  

Ummm - how about the native one ?


--
Lindsay



**

The information contained in, or attached to, this e-mail, contains 
confidential information and is intended solely for the use of the individual 
or entity to whom they are addressed and is subject to legal privilege. If you 
have received this e-mail in error you should notify the sender immediately by 
reply e-mail, delete the message from your system and notify your system 
manager. Please do not copy it for any purpose, or disclose its contents to any 
other person. The views or opinions presented in this e-mail are solely those 
of the author and do not necessarily represent those of the company. The 
recipient should check this e-mail and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused, directly or 
indirectly, by any virus transmitted in this email




Re: [sqlite] Low Level API for SQLite3

2006-05-07 Thread John Stanton
You can get the source code from sqlite.org.  What more do you need if 
you are going to come up with a new version of Sqlite?


You might look to caching compiled (prepared) SQL statements and using 
sqlite3_step as a very powerful method of not just reducing SQL parsing 
time but making it a first time only activity.

JS

Anish Enos Mathew wrote:

Ya, I know about the API's given in sqlite.org. but that does not
contribute much to my reqirements. I want low level API's so that we can
reduce the  parsing time taken by the sqlite parser.

-Original Message-
From: Lindsay [mailto:[EMAIL PROTECTED]

Sent: Monday, May 08, 2006 10:25 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Low Level API for SQLite3

Anish Enos Mathew wrote:


Any body know whether there are any low level  C API's for sqlite3 ?





Ummm - how about the native one ?


--

Lindsay



**

The information contained in, or attached to, this e-mail, contains 
confidential information and is intended solely for the use of the individual 
or entity to whom they are addressed and is subject to legal privilege. If you 
have received this e-mail in error you should notify the sender immediately by 
reply e-mail, delete the message from your system and notify your system 
manager. Please do not copy it for any purpose, or disclose its contents to any 
other person. The views or opinions presented in this e-mail are solely those 
of the author and do not necessarily represent those of the company. The 
recipient should check this e-mail and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused, directly or 
indirectly, by any virus transmitted in this email






RE: [sqlite] Low Level API for SQLite3

2006-05-07 Thread Anish Enos Mathew

Well, currently I am  doing a mobile project and we are testing the
performance of four databases depending on the time it takes to insert
or delete or search a particular data from the database. I am using
sqlite3 database. I am using sqlite_exec command for doing a particular
process in the data base. But the problem with sqlite_exec is that the
sqlite engine should parse the select or insert statement and then
produces the result. If we are having a low level API for doing the same
which doesn't takes parsing time, we could directly do the process
rather than giving the select or insert statements. So I would like to
know is there any other method which can be used to retrieve or insert
data's from the database other than using the select or insert commands.


-Original Message-
From: Lindsay [mailto:[EMAIL PROTECTED]
Sent: Monday, May 08, 2006 10:45 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Low Level API for SQLite3

Anish Enos Mathew wrote:
 Ya, I know about the API's given in sqlite.org. but that does not
 contribute much to my reqirements. I want low level API's so that we
can
 reduce the  parsing time taken by the sqlite parser.
  

Well if you explained what you actually want to do it would help people
help you.

What low level C API's are there is pretty ambigous.



--
Lindsay



**

The information contained in, or attached to, this e-mail, contains 
confidential information and is intended solely for the use of the individual 
or entity to whom they are addressed and is subject to legal privilege. If you 
have received this e-mail in error you should notify the sender immediately by 
reply e-mail, delete the message from your system and notify your system 
manager. Please do not copy it for any purpose, or disclose its contents to any 
other person. The views or opinions presented in this e-mail are solely those 
of the author and do not necessarily represent those of the company. The 
recipient should check this e-mail and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused, directly or 
indirectly, by any virus transmitted in this email