Small. Fast. Reliable.
Choose any three.
*** 26,36 ****
  of precompiling is greatly reduced.
  
  -----
! 
! 22-July-2003:
  
  There is now an *experimental* API in SQLite CVS (checkin [1060]) that 
  can be used for pre-compiled queries:
  
    sqlite_reset( sqlite_vm *, const char **, sqlite_vm ** ppVm);
  
--- 26,37 ----
  of precompiling is greatly reduced.
  
  -----
! 2003-07-22:
  
  There is now an *experimental* API in SQLite CVS (checkin [1060]) that 
  can be used for pre-compiled queries:
+ _(This API has changed as of 2003-09-06.  See below for additional
+ information.)_
  
    sqlite_reset( sqlite_vm *, const char **, sqlite_vm ** ppVm);
  
***************
*** 55,62 ****
  make here.
  
  -----
! 
! 24-July-2003:
  
  Some performance results for pre-compiled queries. The temp db was using the in-memory backend.
  
--- 56,62 ----
  make here.
  
  -----
! 2003-07-24:
  
  Some performance results for pre-compiled queries. The temp db was using the in-memory backend.
  
***************
*** 97,99 ****
--- 97,147 ----
  If you use an INTEGER PRIMARY KEY instead of a PRIMARY KEY things are slightly faster all round. The relative benefit of pre-compiled queries is slightly increased (5-10%) as well.
  
  The program to run this test is {link: http://cvs.hwaci.com/sqlite/attach_get?id=58,precomp_test.c precomp_test.c}. It builds against 2.8.5.
+ 
+ ----
+ 2003-09-06:
+ 
+ The experimental sqlite_reset() API has changed to be the following:
+ 
+     int sqlite_reset(sqlite_vm *pVM, char **pzErrMsg);
+ 
+ Use this routine like sqlite_finalize() after you finish with a run of
+ the virtual machine.  It returns an error code and writes any error
+ message into pzErrMsg.  But instead of deleting the virtual machine,
+ it resets it so that it is ready to run again.  The same VM can be run
+ over and over.
+ 
+ The SQL that you pass to sqlite_compile() can now contain "variables"
+ represented by question marks.  For example:
+ 
+     INSERT INTO tab1 VALUES(?,?,?)
+ 
+ After calling sqlite_compile() or sqlite_reset(), you can fill in the
+ values for the question marks using the new sqlite_bind() API:
+ 
+     sqlite_bind(sqlite_vm *pVm, int idx, const char *zVal, int len, int copy);
+ 
+ The first parameter is the virtual machine you want to bind values to.
+ The second parameter "idx" specifies which variable (or "?") is to
+ receive the value.
+ The variables are number from left to right beginning with 1.  So in the
+ example above, the variables are 1, 2, and 3.  The third parameter is the
+ value to assign to the variable.  The fourth parameter is the length of
+ the data in zVal, including the \000 terminator.  You can use -1 here and
+ sqlite_bind() will figure out the length for itself using strlen().
+ The fifth and last parameter is a flag that is TRUE if you want SQLite to
+ make a copy of the value for itself in memory obtained from malloc().  If
+ the fifth parameter is false, SQLite assumes that zVal is unchanging and
+ that the virtual machine can just whatever memory zVal points to without
+ having to make its own copy.
+ 
+ You can bind the same variable multiple times.  If zVal==0, that is the
+ same as setting the variable to NULL.  Unbound variables are interpreted
+ as NULL.
+ 
+ The "len" parameter (the 4th parameter) is intended to let you insert
+ binary data into the database.  zVal does not really have to be \000
+ terminated - it can be any sequence of bytes you want.  "len" is just the
+ number of bytes in that sequence.  Such is the intent of "len" - but it
+ has not test and any attempts to use it like that at this point will likely
+ encounter bugs.  You have been warned.