diff --git a/main.mk b/main.mk index 2ae10051eb..3bf102cb7b 100644 --- a/main.mk +++ b/main.mk @@ -458,6 +458,9 @@ tclsqlite.html: $(TOP)/www/tclsqlite.tcl vdbe.html: $(TOP)/www/vdbe.tcl tclsh $(TOP)/www/vdbe.tcl >vdbe.html +version3.html: $(TOP)/www/version3.tcl + tclsh $(TOP)/www/version3.tcl >version3.html + # Files to be published on the website. # @@ -493,7 +496,8 @@ DOC = \ sqlite.html \ support.html \ tclsqlite.html \ - vdbe.html + vdbe.html \ + version3.html doc: common.tcl $(DOC) mkdir -p doc diff --git a/manifest b/manifest index ef9bcee6dd..6607334c03 100644 --- a/manifest +++ b/manifest @@ -1,5 +1,5 @@ -C Remove\sredundant\sopcodes\sOP_MakeKey\sand\sOP_MakeIdxKey.\s(CVS\s1612) -D 2004-06-17T07:53:02 +C Documentation\supdates\sin\spreparation\sfor\sthe\srelease\sof\sversion\s3.0.0.\s(CVS\s1613) +D 2004-06-17T19:04:17 F Makefile.in ab7b0d5118e2da97bac66be8684a1034e3500f5a F Makefile.linux-gcc a9e5a0d309fa7c38e7c14d3ecf7690879d3a5457 F README f1de682fbbd94899d50aca13d387d1b3fd3be2dd @@ -17,7 +17,7 @@ F doc/lemon.html f0f682f50210928c07e562621c3b7e8ab912a538 F doc/report1.txt a031aaf37b185e4fa540223cb516d3bccec7eeac F install-sh 9d4de14ab9fb0facae2f48780b874848cbf2f895 F ltmain.sh f6b283068efa69f06eb8aa1fe4bddfdbdeb35826 -F main.mk 26a2e950660b952a98fd2772d4375636a5c9651b +F main.mk 6004a81e05581a6b51e4f37a62ed45db089c47cf F mkdll.sh 68d34a961a1fdfa15ef27fc4f4740be583112124 F publish.sh e772c09c4fb72f2323a1fb522259640e52040b15 F spec.template a38492f1c1dd349fc24cb0565e08afc53045304b @@ -44,19 +44,19 @@ F src/os.h 1cb5f0293a30288451fe3c0c73815cf208212ed1 F src/os_common.h ba1b7306e16e2091718f2c48db0fe6c1d7a31bb8 F src/os_mac.c 3d31e26be1411acfb7961033098631b4f3486fdf F src/os_mac.h 51d2445f47e182ed32d3bd6937f81070c6fd9bd4 -F src/os_unix.c 8832c78dd95c115b1690054354d90321a791950d +F src/os_unix.c 132864ff574571929f51b1b19b47e988a4468404 F src/os_unix.h 1cd6133cf66dea704b8646b70b2dfdcbdd9b3738 F src/os_win.c 337e973ee77797aaab4787e3477a5945fcd97266 F src/os_win.h 004eec47b1780fcaf07420ddc2072294b698d48c F src/pager.c 453099416c10669365ca70f12f13e67e6ef11000 F src/pager.h bc58d32a9dee464f7268fb68652c130a4216e438 F src/parse.y 097438674976355a10cf177bd97326c548820b86 -F src/pragma.c b51bd2034a54f62a72ad454028712afaa294ff94 +F src/pragma.c 83b86b2942d7f1b202644ac4e2559965e23a8a7b F src/printf.c 7e7f83a747bbd0601dcb4ee2885fb3ce3e994a9f F src/random.c eff68e3f257e05e81eae6c4d50a51eb88beb4ff3 F src/select.c 91570af7f13d1c5584f3b711676e1226ee12194e F src/shell.c ca519519dcbbc582f6d88f7d0e7583b857fd3469 -F src/sqlite.h.in 36c253844656186ca53e1999efa6ef7b44f88779 +F src/sqlite.h.in eacd23af3280603cd8b48979c6f9297b3ac2935c F src/sqliteInt.h 59c1e1b637e7cf329f39425469bc4dbeab1fa1d5 F src/table.c af14284fa36c8d41f6829e3f2819dce07d3e2de2 F src/tclsqlite.c 6f88be282a3617c6739c043fd13571b5f2fe9922 @@ -193,24 +193,24 @@ F www/arch2.fig 613b5ac63511109064c2f93c5754ee662219937d F www/arch2.gif 49c6bb36160f03ca2b89eaa5bfb1f560c7d68ee7 F www/audit.tcl 90e09d580f79c7efec0c7d6f447b7ec5c2dce5c0 F www/c_interface.tcl 2176519fc2bd2d2cf6fe74fd806fc2d8362de2c8 -F www/capi3.tcl a940c5ca0b0ebafd5acfe2ceca5a388bd8cfb468 -F www/capi3ref.tcl 7a6e81eebe20b960aed02cb33e369b3645acceec +F www/capi3.tcl 9e6a4b21f464d84b385dd5e78292880fc74a47ab +F www/capi3ref.tcl 68a03fa5c15f01d04fbb073f8153078f1ba6f672 F www/changes.tcl cbe942607b2b9e5dc995395f37042dbb5a629c7f F www/common.tcl f786e6be86fb2627ceb30e770e9efa83b9c67a3a F www/conflict.tcl fb8a2ba83746c7fdfd9e52fa7f6aaf5c422b8246 F www/copyright-release.html 294e011760c439c44951a6bfecd4c81a1ae359e8 F www/copyright-release.pdf cfca3558fc97095e57c6117d08f1f5b80d95125a F www/copyright.tcl 82c9670c7ddb0311912ab7fe24703f33c531066c -F www/datatype3.tcl f48b05cafd5e54ae5c05e643169d5217ee51a244 +F www/datatype3.tcl dadcd0b09dc6fdf86d0c38499e310ae94cb586d7 F www/datatypes.tcl 566004b81c36877397ddbe6e1907aae6065f6b41 -F www/docs.tcl a924a5043973a70c58b65abf1051ed8b1238864d +F www/docs.tcl 095b5718ec044156af477061566ea25632624b56 F www/download.tcl 075e21eb50ec6a3f29cdf2a011770a02187592eb F www/dynload.tcl 02eb8273aa78cfa9070dd4501dca937fb22b466c F www/faq.tcl 3a1776818d9bd973ab0c3048ec7ad6b1ad091ae5 F www/fileformat.tcl f71a06a0d533c7df408539c64113b4adeaf29764 F www/formatchng.tcl d1dfecedfb25e122ab513a1e0948b15cb4f0be46 -F www/index.tcl a3d658c44b27ca28b0b660e2a3903ee39f052dea -F www/lang.tcl fc528581c4a406cabc138e2f17db5ef6f38615ff +F www/index.tcl 9783a8370bf16dfc20e81f1cf14489f95408353e +F www/lang.tcl 608a3504fe59699699ca6faf3f7142e067a9f383 F www/lockingv3.tcl afcd22f0f063989cff2f4d57bbc38d719b4c6e75 F www/mingw.tcl d96b451568c5d28545fefe0c80bee3431c73f69c F www/nulls.tcl f31330db8c978e675f5cd263067b32b822effa6f @@ -223,8 +223,9 @@ F www/sqlite.tcl b51fd15f0531a54874de785a9efba323eecd5975 F www/support.tcl 1801397edd271cc39a2aadd54e701184b5181248 F www/tclsqlite.tcl 19191cf2a1010eaeff74c51d83fd5f5a4d899075 F www/vdbe.tcl 59288db1ac5c0616296b26dce071c36cb611dfe9 +F www/version3.tcl f9a4c1a12864e129f6717d22313be01d5657e3aa F www/whentouse.tcl a8335bce47cc2fddb07f19052cb0cb4d9129a8e4 -P 12e77e759ec5b45b7fb94aa815435127f395162e -R aebc8fd8caefcbe7b2df44794110fc94 -U danielk1977 -Z f3b130fff0bc0063d640a9d3c08bfe60 +P a71a9ff114f2162696d8d37fbc87b315568f6dcb +R 0c1c395d17282923e97a25ac9186d69a +U drh +Z 95db50b2b10478702338303008862d5b diff --git a/manifest.uuid b/manifest.uuid index 5222e9f09f..7c7b49ec56 100644 --- a/manifest.uuid +++ b/manifest.uuid @@ -1 +1 @@ -a71a9ff114f2162696d8d37fbc87b315568f6dcb \ No newline at end of file +9fb29f7331254b601b71f0fe7d77f91915272dc7 \ No newline at end of file diff --git a/src/os_unix.c b/src/os_unix.c index 9087347fc9..c096b6a00e 100644 --- a/src/os_unix.c +++ b/src/os_unix.c @@ -607,17 +607,22 @@ int sqlite3OsSeek(OsFile *id, off_t offset){ int sqlite3OsSync(OsFile *id){ SimulateIOError(SQLITE_IOERR); TRACE2("SYNC %-3d\n", id->h); +{ +off_t sz; +sqlite3OsFileSize(id, &sz); +fprintf(stderr,"SYNC %d size=%lld... ", id->h, sz); +} if( fsync(id->h) ){ return SQLITE_IOERR; - }else{ - if( id->dirfd>=0 ){ - TRACE2("DIRSYNC %-3d\n", id->dirfd); - fsync(id->dirfd); - close(id->dirfd); /* Only need to sync once, so close the directory */ - id->dirfd = -1; /* when we are done. */ - } - return SQLITE_OK; } + if( id->dirfd>=0 ){ + TRACE2("DIRSYNC %-3d\n", id->dirfd); + fsync(id->dirfd); + close(id->dirfd); /* Only need to sync once, so close the directory */ + id->dirfd = -1; /* when we are done. */ + } +fprintf(stderr,"DONE\n"); + return SQLITE_OK; } /* diff --git a/src/pragma.c b/src/pragma.c index 8a9dabd594..2b5f91ca39 100644 --- a/src/pragma.c +++ b/src/pragma.c @@ -11,7 +11,7 @@ ************************************************************************* ** This file contains code used to implement the PRAGMA command. ** -** $Id: pragma.c,v 1.45 2004/06/16 12:02:43 danielk1977 Exp $ +** $Id: pragma.c,v 1.46 2004/06/17 19:04:17 drh Exp $ */ #include "sqliteInt.h" #include @@ -124,10 +124,12 @@ static int flagPragma(Parse *pParse, const char *zLeft, const char *zRight){ { "vdbe_trace", SQLITE_VdbeTrace }, { "sql_trace", SQLITE_SqlTrace }, { "vdbe_listing", SQLITE_VdbeListing }, +#if 1 /* FIX ME: Remove the following pragmas */ { "full_column_names", SQLITE_FullColNames }, { "short_column_names", SQLITE_ShortColNames }, { "count_changes", SQLITE_CountRows }, { "empty_result_callbacks", SQLITE_NullCallback }, +#endif }; int i; for(i=0; i

The API for version 3.0 is similar to the version 2.X API, @@ -48,12 +49,37 @@ to whatever datatype is appropriate for their system.

2.0 C/C++ Interface

+

+The API for SQLite 3.0 three includes 83 separate functions in addition +to several data structures and #defines. (A complete +API reference is provided as a separate document.) +Fortunately, the interface is not nearly as complex as its size implies. +Simple programs can still make due with only 3 functions: +sqlite3_open(), +sqlite3_exec(), and +sqlite3_close(). +More control over the execution of the database engine is provided +using +sqlite3_prepare() +to compile an SQLite statement into byte code and +sqlite3_step() +to execute that bytecode. +A family of routines with names beginning with +sqlite3_column_ +is used to extract informatiom about the result set of a query. +Many interface functions come in pairs, with both a UTF-8 and +and UTF-16 version. And there is a collection of routines +used to implement user-defined SQL functions and user-defined +text collating sequences. +

+ +

2.1 Opening and closing a database

    typedef struct sqlite3 sqlite3;
-   int sqlite3_open(const char*, sqlite3**, const char**);
-   int sqlite3_open16(const void*, sqlite3**, const char**);
+   int sqlite3_open(const char*, sqlite3**);
+   int sqlite3_open16(const void*, sqlite3**);
    int sqlite3_close(sqlite3*);
    const char *sqlite3_errmsg(sqlite3*);
    const void *sqlite3_errmsg16(sqlite3*);
@@ -62,7 +88,8 @@ to whatever datatype is appropriate for their system.
 
 

 The sqlite3_open() routine returns an integer error code rather than
-a pointer to the sqlite3 structure.  The difference between sqlite3_open()
+a pointer to the sqlite3 structure as the version 2 interface did.
+The difference between sqlite3_open()
 and sqlite3_open16() is that sqlite3_open16() takes UTF-16 (in host native
 byte order) for the name of the database file.  If a new database file
 needs to be created, then sqlite3_open16() will set the internal text
@@ -71,12 +98,10 @@ representation to UTF-8.
 

 
 

-The third "const char**" argument to sqlite3_open() is a NULL-terminated
-list of keyword/value pairs that define options to apply to the open
-request.  The third argument may be NULL if there are no options.
-This extra argument provides an expandable way of supporting new features
-in future releases.  For example, a future release may contain an
-option to define an encryption/decryption key.
+The opening and/or creating of the database file is deferred until the
+file is actually needed.  This allows options and parameters, such
+as the native text representation and default page size, to be
+set using PRAGMA statements.
 

 
 

@@ -125,25 +150,57 @@ They are as follows:
 
 
2.2 Executing SQL statements

 
+
+   typedef int (*sqlite_callback)(void*,int,char**, char**);
+   int sqlite3_exec(sqlite3*, const char *sql, sqlite_callback, void*, char**);
+

+
+

+The sqlite3_exec function works much as it did in SQLite version 2.
+Zero or more SQL statements specified in the second parameter are compiled
+and executed.  Query results are returned to a callback routine.
+See the API reference for additional
+information.
+

+
+

+In SQLite version 3, the sqlite3_exec routine is just a wrapper around
+calls to the prepared statement interface.
+

+
 
    typedef struct sqlite3_stmt sqlite3_stmt;
-   int sqlite3_prepare(sqlite3*, const char*, sqlite3_stmt**, const char**);
-   int sqlite3_prepare16(sqlite3*, const void*, sqlite3_stmt**, const void**);
+   int sqlite3_prepare(sqlite3*, const char*, int, sqlite3_stmt**, const char**);
+   int sqlite3_prepare16(sqlite3*, const void*, int, sqlite3_stmt**, const void**);
    int sqlite3_finalize(sqlite3_stmt*);
    int sqlite3_reset(sqlite3_stmt*);
 

 
 

-The non-callback API is now the preferred way of accessing the database.
-Wrapper functions that emulate the older callback API may (or may not)
-be provided.
+The sqlite3_prepare interface compiles a single SQL statement into byte code
+for later execution.
+This interface is now the preferred way of accessing the database.
 

 
 

-The sqlite3_prepare() function compiles an single SQL statement.
-The statement may contain tokens of the form "?" or "?nnn" or ":nnn:"
+The SQL statement is a UTF-8 string for sqlite3_prepare().
+The sqlite3_prepare16() works the same way except
+that it expects a UTF-16 string as SQL input.
+Only the first SQL statement in the input string is compiled.
+The fourth parameter is filled in with a pointer to the next (uncompiled)
+SQLite statement in the input string, if any.
+The sqlite3_finalize() routine deallocates a prepared SQL statement.
+All prepared statements must be finalized before the database can be
+closed.
+The sqlite3_reset() routine resets a prepared SQL statement so that it
+can be executed again.
+

+
+

+The SQL statement may contain tokens of the form "?" or "?nnn" or ":nnn:"
 where "nnn" is an integer.  Such tokens represent unspecified literal values
-(or wildcard) to be filled in later by the sqlite3_bind() API.
+(or wildcards) to be filled in later by the 
+sqlite3_bind interface.
 Each wildcard as an associated number given
 by the "nnn" that follows the "?".  If the "?" is not followed by an
 integer, then its number one more than the number of prior wildcards
@@ -153,26 +210,14 @@ all instance of that wildcard will be filled in with the same value.
 Unbound wildcards have a value of NULL.
 

 
-
-
The SQL statement is a UTF-8 string for sqlite3_prepare().
-The sqlite3_prepare16() works the same way except
-that it expects a UTF-16 string as SQL input.
-Only the first SQL statement in the input string is compiled.
-The fourth parameter is filled in with a pointer to the next (uncompiled)
-SQLite statement in the input string, if any.
-The sqlite3_finalize() routine deallocates a prepared SQL statement.
-The sqlite3_reset() routine resets a prepared SQL statement so that it
-can be executed again.
-

-
 
-   int sqlite3_bind_blob(sqlite3_stmt*, int, const void*, int n, int eCopy);
+   int sqlite3_bind_blob(sqlite3_stmt*, int, const void*, int n, void(*)(void*));
    int sqlite3_bind_double(sqlite3_stmt*, int, double);
    int sqlite3_bind_int(sqlite3_stmt*, int, int);
    int sqlite3_bind_int64(sqlite3_stmt*, int, long long int);
    int sqlite3_bind_null(sqlite3_stmt*, int);
-   int sqlite3_bind_text(sqlite3_stmt*, int, const char*, int n, int eCopy);
-   int sqlite3_bind_text16(sqlite3_stmt*, int, const void*, int n, int eCopy);
+   int sqlite3_bind_text(sqlite3_stmt*, int, const char*, int n, void(*)(void*));
+   int sqlite3_bind_text16(sqlite3_stmt*, int, const void*, int n, void(*)(void*));
    int sqlite3_bind_value(sqlite3_stmt*, int, const sqlite3_value*);
 

 
@@ -202,26 +247,38 @@ of the result set:
 

 
 
-   int sqlite3_column_count(sqlite3_stmt*);
-   int sqlite3_column_type(sqlite3_stmt*,int);
-   const char *sqlite3_column_decltype(sqlite3_stmt *, int i);
-   const char *sqlite3_column_decltype16(sqlite3_stmt *, int i);
-   const char *sqlite3_column_name(sqlite3_stmt*,int);
-   const void *sqlite3_column_name16(sqlite3_stmt*,int);
    const void *sqlite3_column_blob(sqlite3_stmt*, int iCol);
    int sqlite3_column_bytes(sqlite3_stmt*, int iCol);
    int sqlite3_column_bytes16(sqlite3_stmt*, int iCol);
+   int sqlite3_column_count(sqlite3_stmt*);
+   const char *sqlite3_column_decltype(sqlite3_stmt *, int iCol);
+   const void *sqlite3_column_decltype16(sqlite3_stmt *, int iCol);
    double sqlite3_column_double(sqlite3_stmt*, int iCol);
    int sqlite3_column_int(sqlite3_stmt*, int iCol);
    long long int sqlite3_column_int64(sqlite3_stmt*, int iCol);
+   const char *sqlite3_column_name(sqlite3_stmt*, int iCol);
+   const void *sqlite3_column_name16(sqlite3_stmt*, int iCol);
    const unsigned char *sqlite3_column_text(sqlite3_stmt*, int iCol);
    const void *sqlite3_column_text16(sqlite3_stmt*, int iCol);
    int sqlite3_column_type(sqlite3_stmt*, int iCol);
 

 
 

-The sqlite3_column_count() function returns the number of columns in
-the results set.   The sqlite3_column_type() function returns the
+The 
+sqlite3_column_count()
+function returns the number of columns in
+the results set.  sqlite3_column_count() can be called at any time after
+sqlite3_prepare().  
+sqlite3_data_count()
+works similarly to
+sqlite3_column_count() except that it only works following sqlite3_step().
+If the previous call to sqlite3_step() returned SQLITE_DONE or an error code,
+then sqlite3_data_count() will return 0 whereas sqlite3_column_count() will
+continue to return the number of columns in the result set.
+

+
+

+The sqlite3_column_type() function returns the
 datatype for the value in the Nth column.  The return value is one
 of these:
 

@@ -252,6 +309,12 @@ sqlite3_column_int64() returns 64-bit INTEGER data.
 Finally, sqlite3_column_double() return floating point data.
 

 
+

+It is not necessary to retrieve data in the format specify by
+sqlite3_column_type().  If a different format is requested, the data
+is converted automatically.
+

+
 
2.3 User-defined functions

 
 

@@ -265,7 +328,6 @@ User defined functions can be created using the following routine:
      const char *zFunctionName,
      int nArg,
      int eTextRep,
-     int iCollateArg,
      void*,
      void (*xFunc)(sqlite3_context*,int,sqlite3_value**),
      void (*xStep)(sqlite3_context*,int,sqlite3_value**),
@@ -276,16 +338,16 @@ User defined functions can be created using the following routine:
      const void *zFunctionName,
      int nArg,
      int eTextRep,
-     int iCollateArg,
      void*,
      void (*xFunc)(sqlite3_context*,int,sqlite3_value**),
      void (*xStep)(sqlite3_context*,int,sqlite3_value**),
      void (*xFinal)(sqlite3_context*)
    );
    #define SQLITE3_UTF8     1
-   #define SQLITE3_UTF16LE  2
+   #define SQLITE3_UTF16    2
    #define SQLITE3_UTF16BE  3
-   #define SQLITE3_ANY      4
+   #define SQLITE3_UTF16LE  4
+   #define SQLITE3_ANY      5

@@ -297,9 +359,6 @@ be one of the parameters defined above. SQLite version 3 allows multiple implementations of the same function using different text representations. The database engine chooses the function that minimization the number of text conversions required. -The iCollateArg parameter indicates that the collating sequence for the -result is to be the same as the collating sequence of the iCollateArg-th -parameter.

@@ -341,15 +400,15 @@ to report results: 

    void *sqlite3_aggregate_context(sqlite3_context*, int nbyte);
    void *sqlite3_user_data(sqlite3_context*);
-   void sqlite3_result_blob(sqlite3_context*, const void*, int n, int eCopy);
+   void sqlite3_result_blob(sqlite3_context*, const void*, int n, void(*)(void*));
    void sqlite3_result_double(sqlite3_context*, double);
    void sqlite3_result_error(sqlite3_context*, const char*, int);
    void sqlite3_result_error16(sqlite3_context*, const void*, int);
    void sqlite3_result_int(sqlite3_context*, int);
    void sqlite3_result_int64(sqlite3_context*, long long int);
    void sqlite3_result_null(sqlite3_context*);
-   void sqlite3_result_text(sqlite3_context*, const char*, int n, int eCopy);
-   void sqlite3_result_text16(sqlite3_context*, const void*, int n, int eCopy);
+   void sqlite3_result_text(sqlite3_context*, const char*, int n, void(*)(void*));
+   void sqlite3_result_text16(sqlite3_context*, const void*, int n, void(*)(void*));
    void sqlite3_result_value(sqlite3_context*, sqlite3_value*);
    void *sqlite3_get_auxdata(sqlite3_context*, int);
    void sqlite3_set_auxdata(sqlite3_context*, int, void*, void (*)(void*));
diff --git a/www/capi3ref.tcl b/www/capi3ref.tcl
index 45542921a2..723aff78d3 100644
--- a/www/capi3ref.tcl
+++ b/www/capi3ref.tcl
@@ -1,4 +1,4 @@
-set rcsid {$Id: capi3ref.tcl,v 1.3 2004/06/12 00:42:36 danielk1977 Exp $}
+set rcsid {$Id: capi3ref.tcl,v 1.4 2004/06/17 19:04:17 drh Exp $}
 source common.tcl
 header {C/C++ Interface For SQLite Version 3}
 puts {
@@ -43,8 +43,8 @@ api {result-codes} {
 #define SQLITE_ROW         100  /* sqlite_step() has another row ready */
 #define SQLITE_DONE        101  /* sqlite_step() has finished executing */
 } {
-The sqlite3.h header file defines macros for the integer result codes
-returned by many API functions.
+Many SQLite functions return an integer result code from the set shown
+above in order to indicates success or failure.
 }
 
 api {} {
@@ -76,8 +76,8 @@ api {} {
   int sqlite3_bind_null(sqlite3_stmt*, int);
   int sqlite3_bind_text(sqlite3_stmt*, int, const char*, int n, void(*)(void*));
   int sqlite3_bind_text16(sqlite3_stmt*, int, const void*, int n, void(*)(void*));
-  #define SQLITE_STATIC      ((void*)0)
-  #define SQLITE_EPHEMERAL   ((void*)8)
+  #define SQLITE_STATIC      ((void(*)(void *))0)
+  #define SQLITE_TRANSIENT   ((void(*)(void *))-1)
 } {
  In the SQL strings input to sqlite3_prepare() and sqlite3_prepare16(),
  one or more literals can be replace by a wildcard "?" or ":N:" where
@@ -94,7 +94,7 @@ api {} {
  text after SQLite has finished with it.  If the fifth argument is the
  special value SQLITE_STATIC, then the library assumes that the information
  is in static, unmanaged space and does not need to be freed.  If the
- fifth argument has the value SQLITE_EPHEMERAL, then SQLite makes its
+ fifth argument has the value SQLITE_TRANSIENT, then SQLite makes its
  on private copy of the data.
 
  The sqlite3_bind_*() routine must be called after
@@ -104,7 +104,7 @@ api {} {
 }
 
 api {} {
-  void sqlite3_busy_handler(sqlite*, int(*)(void*,int), void*);
+  int sqlite3_busy_handler(sqlite*, int(*)(void*,int), void*);
 } {
  This routine identifies a callback function that is invoked
  whenever an attempt is made to open a database table that is
@@ -129,7 +129,7 @@ api {} {
 }
 
 api {} {
-  void sqlite3_busy_timeout(sqlite*, int ms);
+  int sqlite3_busy_timeout(sqlite*, int ms);
 } {
  This routine sets a busy handler that sleeps for a while when a
  table is locked.  The handler will sleep multiple times until 
@@ -142,18 +142,19 @@ api {} {
 }
 
 api {} {
-int sqlite3_changes(sqlite*);
+  int sqlite3_changes(sqlite*);
 } {
  This function returns the number of database rows that were changed
- (or inserted or deleted) by the most recent called sqlite3_exec().
+ (or inserted or deleted) by the most recently completed
+ INSERT, UPDATE, or DELETE
+ statement.  Only changes that are directly specified by the INSERT,
+ UPDATE, or DELETE statement are counted.  Auxiliary changes caused by
+ triggers are not counted.  Use the sqlite3_total_changes() function
+ to find the total number of changes including changes caused by triggers.
 
- All changes are counted, even if they were later undone by a
- ROLLBACK or ABORT.  Except, changes associated with creating and
- dropping tables are not counted.
-
- If a callback invokes sqlite3_exec() recursively, then the changes
- in the inner, recursive call are counted together with the changes
- in the outer call.
+ Within the body of a trigger, the sqlite3_changes() function does work
+ to report the number of rows that were changed for the most recently
+ completed INSERT, UPDATE, or DELETE statement within the trigger body.
 
  SQLite implements the command "DELETE FROM table" without a WHERE clause
  by dropping and recreating the table.  (This is much faster than going
@@ -165,11 +166,39 @@ int sqlite3_changes(sqlite*);
 }
 
 api {} {
-  void sqlite3_close(sqlite *);
+  int sqlite3_total_changes(sqlite*);
 } {
- Call this function with a pointer to a structure that was previously
- returned from sqlite3_open() or sqlite3_open16()
- and the corresponding database will by closed.
+  This function returns the total number of database rows that have
+  be modified, inserted, or deleted since the database connection was
+  created using sqlite3_open().  All changes are counted, including
+  changes by triggers and changes to TEMP and auxiliary databases.
+  Except, changes to the SQLITE_MASTER table (caused by statements 
+  such as CREATE TABLE) are not counted.  Nor are changes counted when
+  an entire table is deleted using DROP TABLE.
+
+  See also the sqlite3_changes() API.
+
+  SQLite implements the command "DELETE FROM table" without a WHERE clause
+  by dropping and recreating the table.  (This is much faster than going
+  through and deleting individual elements form the table.)  Because of
+  this optimization, the change count for "DELETE FROM table" will be
+  zero regardless of the number of elements that were originally in the
+  table. To get an accurate count of the number of rows deleted, use
+  "DELETE FROM table WHERE 1" instead.
+}
+
+api {} {
+  int sqlite3_close(sqlite *);
+} {
+  Call this function with a pointer to a structure that was previously
+  returned from sqlite3_open() or sqlite3_open16()
+  and the corresponding database will by closed.
+
+  SQLITE_OK is returned if the close is successful.  If there are
+  prepared statements that have not been finalized, then SQLITE_BUSY
+  is returned.  SQLITE_ERROR might be returned if the argument is not
+  a valid connection pointer returned by sqlite3_open() or if the connection
+  pointer has been closed previously.
 }
 
 api {} {
@@ -229,16 +258,18 @@ int sqlite3_column_type(sqlite3_stmt*, int iCol);
 api {} {
 int sqlite3_column_count(sqlite3_stmt *pStmt);
 } {
- Return the number of columns in the result set returned by the compiled
+ Return the number of columns in the result set returned by the prepared
  SQL statement. This routine returns 0 if pStmt is an SQL statement
  that does not return data (for example an UPDATE).
+
+ See also sqlite3_data_count().
 }
 
 api {} {
 const char *sqlite3_column_decltype(sqlite3_stmt *, int i);
 const void *sqlite3_column_decltype16(sqlite3_stmt*,int);
 } {
- The first parameter is a compiled SQL statement. If this statement
+ The first parameter is a prepared SQL statement. If this statement
  is a SELECT statement, the Nth column of the returned result set 
  of the SELECT is a table column then the declared type of the table
  column is returned. If the Nth column of the result set is not at table
@@ -266,38 +297,27 @@ api {} {
 const char *sqlite3_column_name(sqlite3_stmt*,int);
 const void *sqlite3_column_name16(sqlite3_stmt*,int);
 } {
- The first parameter is a compiled SQL statement. This function returns
+ The first parameter is a prepared SQL statement. This function returns
  the column heading for the Nth column of that statement, where N is the
  second function parameter.  The string returned is UTF-8 for
  sqlite3_column_name() and UTF-16 for sqlite3_column_name16().
 }
 
 api {} {
-void *sqlite3_commit_hook(sqlite*, int(*)(void*), void*);
+void *sqlite3_commit_hook(sqlite*, int(*xCallback)(void*), void *pArg);
 } {
- This routine configures a callback function - the progress callback - that
- is invoked periodically during long running calls to sqlite3_exec(),
- sqlite3_step() and sqlite3_get_table().
- An example use for this API is to keep
- a GUI updated during a large query.
+ Experimental
 
- The progress callback is invoked once for every N virtual machine opcodes,
- where N is the second argument to this function. The progress callback
- itself is identified by the third argument to this function. The fourth
- argument to this function is a void pointer passed to the progress callback
- function each time it is invoked.
+ Register a callback function to be invoked whenever a new transaction
+ is committed.  The pArg argument is passed through to the callback.
+ callback.  If the callback function returns non-zero, then the commit
+ is converted into a rollback.
 
- If a call to sqlite3_exec(), sqlite3_step() or sqlite3_get_table() results 
- in less than N opcodes being executed, then the progress callback is not
- invoked.
- 
- To remove the progress callback altogether, pass NULL as the third
- argument to this function.
+ If another function was previously registered, its pArg value is returned.
+ Otherwise NULL is returned.
 
- If the progress callback returns a result other than 0, then the current 
- query is immediately terminated and any database changes rolled back. If the
- query was part of a larger transaction, then the transaction is not rolled
- back and remains active. The sqlite3_exec() call returns SQLITE_ABORT. 
+ Registering a NULL function disables the callback.  Only a single commit
+ hook callback can be registered at a time.
 }
 
 api {} {
@@ -345,7 +365,9 @@ int sqlite3_create_collation16(
  The third argument must be one of the constants SQLITE_UTF8,
  SQLITE_UTF16LE or SQLITE_UTF16BE, indicating that the user-supplied
  routine expects to be passed pointers to strings encoded using UTF-8,
- UTF-16 little-endian or UTF-16 big-endian respectively.
+ UTF-16 little-endian or UTF-16 big-endian respectively.  The
+ SQLITE_UTF16 constant indicates that text strings are expected in
+ UTF-16 in the native byte order of the host machine.
 
  A pointer to the user supplied routine must be passed as the fifth
  argument. If it is NULL, this is the same as deleting the collation
@@ -404,7 +426,6 @@ int sqlite3_create_function(
   const char *zFunctionName,
   int nArg,
   int eTextRep,
-  int iCollateArg,
   void*,
   void (*xFunc)(sqlite3_context*,int,sqlite3_value**),
   void (*xStep)(sqlite3_context*,int,sqlite3_value**),
@@ -415,7 +436,6 @@ int sqlite3_create_function16(
   const void *zFunctionName,
   int nArg,
   int eTextRep,
-  int iCollateArg,
   void*,
   void (*xFunc)(sqlite3_context*,int,sqlite3_value**),
   void (*xStep)(sqlite3_context*,int,sqlite3_value**),
@@ -443,7 +463,7 @@ int sqlite3_create_function16(
  aggregate takes. If this parameter is negative, then the function or
  aggregate may take any number of arguments.
 
- The seventh, eighth and ninth parameters, xFunc, xStep and xFinal, are
+ The sixth, seventh and  eighth, xFunc, xStep and xFinal, are
  pointers to user implemented C functions that implement the user
  function or aggregate. A scalar function requires an implementation of
  the xFunc callback only, NULL pointers should be passed as the xStep
@@ -464,7 +484,7 @@ int sqlite3_data_count(sqlite3_stmt *pStmt);
  will return the same value as the sqlite3_column_count() function.
  After sqlite3_step() has returned an SQLITE_DONE, SQLITE_BUSY or
  error code, or before sqlite3_step() has been called on a 
- compiled SQL statement, this routine returns zero.
+ prepared SQL statement, this routine returns zero.
 }
 
 api {} {
@@ -550,12 +570,15 @@ int sqlite3_exec(
 api {} {
 int sqlite3_finalize(sqlite3_stmt *pStmt);
 } {
- The sqlite3_finalize() function is called to delete a compiled
+ The sqlite3_finalize() function is called to delete a prepared
  SQL statement obtained by a previous call to sqlite3_prepare()
  or sqlite3_prepare16(). If the statement was executed successfully, or
  not executed at all, then SQLITE_OK is returned. If execution of the
  statement failed then an error code is returned. 
 
+ All prepared statements must finalized before sqlite3_close() is
+ called or else the close will fail with a return code of SQLITE_BUSY.
+
  This routine can be called at any point during the execution of the
  virtual machine.  If the virtual machine has not completed execution
  when this routine is called, that is like encountering an error or
@@ -637,12 +660,6 @@ api {sqlite3_interrupt} {
  immediately.
 } {}
 
-api {} {
-int sqlite3_last_statement_changes(sqlite*);
-} {
-Experimental
-}
-
 api {} {
 long long int sqlite3_last_insert_rowid(sqlite*);
 } {
@@ -810,7 +827,7 @@ void sqlite3_progress_handler(sqlite*, int, int(*)(void*), void*);
 api {} {
 int sqlite3_reset(sqlite3_stmt *pStmt);
 } {
- The sqlite3_reset() function is called to reset a compiled SQL
+ The sqlite3_reset() function is called to reset a prepared SQL
  statement obtained by a previous call to sqlite3_prepare() or
  sqlite3_prepare16() back to it's initial state, ready to be re-executed.
  Any SQL statement variables that had values bound to them using
@@ -834,6 +851,10 @@ void sqlite3_result_value(sqlite3_context*, sqlite3_value*);
  User-defined functions invoke the following routines in order to
  set their return value.  The sqlite3_result_value() routine is used
  to return an exact copy of one of the parameters to the function.
+
+ The operation of these routines is very similar to the operation of
+ sqlite3_bind_blob() and its cousins.  Refer to the documentation there
+ for additional information.
 }
 
 api {} {
@@ -842,7 +863,6 @@ int sqlite3_set_authorizer(
   int (*xAuth)(void*,int,const char*,const char*,const char*,const char*),
   void *pUserData
 );
-#define SQLITE_COPY                  0   /* Table Name      File Name       */
 #define SQLITE_CREATE_INDEX          1   /* Index Name      Table Name      */
 #define SQLITE_CREATE_TABLE          2   /* Table Name      NULL            */
 #define SQLITE_CREATE_TEMP_INDEX     3   /* Index Name      Table Name      */
@@ -896,7 +916,7 @@ int sqlite3_set_authorizer(
 api {} {
 int sqlite3_step(sqlite3_stmt*);
 } {
- After an SQL query has been compiled with a call to either
+ After an SQL query has been prepared with a call to either
  sqlite3_prepare() or sqlite3_prepare16(), then this function must be
  called one or more times to execute the statement.
 
@@ -994,12 +1014,14 @@ for {set j 0} {$j<3} {incr j} {
   puts {
    }
   while {$i<$limit && $i<$n} {
     set name $sname($i)
-    puts "
  • $name
    • "
+    if {[regexp {^sqlite} $name]} {set display $name} {set display $name}
+    puts "
  • $display
    • "
     incr i
   }
   puts {
}
 }
 puts ""
+puts ""
 
 proc resolve_name {ignore_list name} {
   global name_to_idx
diff --git a/www/datatype3.tcl b/www/datatype3.tcl
index 601a6da6cd..31033cbb84 100644
--- a/www/datatype3.tcl
+++ b/www/datatype3.tcl
@@ -1,4 +1,4 @@
-set rcsid {$Id: datatype3.tcl,v 1.5 2004/06/10 10:51:53 danielk1977 Exp $}
+set rcsid {$Id: datatype3.tcl,v 1.6 2004/06/17 19:04:17 drh Exp $}
 source common.tcl
 header {Datatypes In SQLite Version 3}
 puts {
@@ -309,8 +309,8 @@ instead of memcmp().
 
  
 

 Aside from the default collation sequence BINARY, implemented using
-memcmp(), SQLite features two extra built-in collation sequences,
-NOCASE and REVERSE:
+memcmp(), SQLite features two extra built-in collation sequences 
+intended for testing purposes, NOCASE and REVERSE:
 
  
 
    
 	
  • BINARY - Compares string data using memcmp(), regardless
diff --git a/www/docs.tcl b/www/docs.tcl
index 5425826e19..828a34aad5 100644
--- a/www/docs.tcl
+++ b/www/docs.tcl
@@ -1,7 +1,7 @@
 # This script generates the "docs.html" page that describes various
 # sources of documentation available for SQLite.
 #
-set rcsid {$Id: docs.tcl,v 1.4 2004/06/11 17:48:04 drh Exp $}
+set rcsid {$Id: docs.tcl,v 1.5 2004/06/17 19:04:17 drh Exp $}
 source common.tcl
 header {SQLite Documentation}
 puts {
@@ -28,6 +28,9 @@ doc {Version 2 C/C++ API} {c_interface.html} {
   A description of the C/C++ interface bindings for SQLite through version 
   2.8
 }
+doc {SQLite Version 3} {version3.html} {
+  A summary of of the changes between SQLite version 2.8 and SQLite version 3.0.
+}
 doc {Version 3 C/C++ API} {capi3.html} {
   A description of the C/C++ interface bindings for SQLite version 3.0.0
   and following.
diff --git a/www/index.tcl b/www/index.tcl
index c07e70ddd2..88c3daec5f 100644
--- a/www/index.tcl
+++ b/www/index.tcl
@@ -60,13 +60,14 @@ proc newsitem {date title text} {
 
 newsitem {2004-Jun-18} {Version 3.0.0 (alpha) Released} {
   The first alpha release of SQLite version 3.0 is available for
-  public review and comment.  Version 3.0 enhances i18n support
+  public review and comment.  Version 3.0 enhances internationalization support
   through the use of UTF-16 and user-defined text collating sequences.
   BLOBs can now be stored directly, without encoding.
   A new file format results in databases that are 25% smaller (depending
   on content).  The code is also a little faster.  In spite of the many
-  new features, the library footprint is still less than 235KB
+  new features, the library footprint is still less than 240KB
   (x86, gcc -O1).
+  Additional information.
 
   Our intent is to freeze the file format and API on 2004-Jul-01.
   Users are encouraged to review and evaluate this alpha release carefully 
@@ -87,4 +88,4 @@ puts {
 
    Old news...
    
 
 }
-footer {$Id: index.tcl,v 1.87 2004/06/16 03:02:04 drh Exp $}
+footer {$Id: index.tcl,v 1.88 2004/06/17 19:04:17 drh Exp $}
diff --git a/www/lang.tcl b/www/lang.tcl
index 01c8179904..1dbda95582 100644
--- a/www/lang.tcl
+++ b/www/lang.tcl
@@ -1,7 +1,7 @@
 #
 # Run this Tcl script to generate the sqlite.html file.
 #
-set rcsid {$Id: lang.tcl,v 1.68 2004/05/31 15:06:30 drh Exp $}
+set rcsid {$Id: lang.tcl,v 1.69 2004/06/17 19:04:17 drh Exp $}
 source common.tcl
 header {Query Language Understood by SQLite}
 puts {
@@ -129,9 +129,10 @@ temporary tables.  These cannot be detached.  Attached databases
 are removed using the DETACH DATABASE 
 statement.
    
 
-
    You can read from and write to an attached database, but you cannot 
-alter the schema of an attached database.  You can only CREATE and 
-DROP in the original database.
    
+
    You can read from and write to an attached database and you
+can modify the schema of the attached database.  This is a new
+feature of SQLite version 3.0.  In SQLite 2.8, schema changes
+to attached databases were not allows.
    
 
 
    You cannot create a new table with the same name as a table in 
 an attached database, but you can attach a database which contains
@@ -147,25 +148,28 @@ of that name.  Any tables of that name attached afterwards require the table
 prefix. If the 'default' table of a given name is detached, then 
 the last table of that name attached becomes the new default.
    
 
-
    When there are attached databases, transactions are not atomic. 
-Transactions continue to be atomic within each individual
-database file. But if your machine crashes in the middle
-of a COMMIT where you have updated two or more database
-files, some of those files might get the changes where others
-might not.
    
+
    
+Transactions involving multiple attached databases are atomic,
+assuming that the main database is not ":memory:".  If the main
+database is ":memory:" then 
+transactions continue to be atomic within each individual
+database file. But if the host computer crashes in the middle
+of a COMMIT where two or more database files are updated,
+some of those files might get the changes where others
+might not.
+Atomic commit of attached databases is a new feature of SQLite version 3.0.
+In SQLite version 2.8, all commits to attached databases behaved as if
+the main database were ":memory:".
+
    
 
 
    There is a compile-time limit of 10 attached database files.
    
-
-
    Executing a BEGIN TRANSACTION statement locks all database
-files, so this feature cannot (currently) be used to increase 
-concurrancy.
    
 }
 
 
 Section {BEGIN TRANSACTION} transaction
 
 Syntax {sql-statement} {
-BEGIN [TRANSACTION []] [ON CONFLICT ]
+BEGIN [TRANSACTION []]
 }
 Syntax {sql-statement} {
 END [TRANSACTION []]
@@ -183,8 +187,7 @@ rollback and atomic commit.  See ATTACH for
 an exception when there are attached databases.
    
 
 
    The optional transaction name is ignored. SQLite currently 
-doesn't allow nested transactions.  Attempting to start a new 
-transaction inside another is an error.
    
+does not allow nested transactions.
    
 
 
    
 No changes can be made to the database except within a transaction.
@@ -206,14 +209,18 @@ conflict resolution algorithm.
 
    
 
 
    
-The optional ON CONFLICT clause at the end of a BEGIN statement
-can be used to changed the default conflict resolution algorithm.
-The normal default is ABORT.  If an alternative is specified by
-the ON CONFLICT clause of a BEGIN, then that alternative is used
-as the default for all commands within the transaction.  The default
-algorithm is overridden by ON CONFLICT clauses on individual
-constraints within the CREATE TABLE or CREATE INDEX statements
-and by the OR clauses on COPY, INSERT, and UPDATE commands.
+The COMMIT command does not actually perform a commit until all
+pending SQL commands finish.  Thus if two or more SELECT statements
+are in the middle of processing and a COMMIT is executed, the commit
+will not actually occur until all SELECT statements finish.
+
    
+
+
    
+An attempt to execute COMMIT might result in an SQLITE_BUSY return code.
+This indicates that another thread or process had a read lock on the database
+that prevented the database from being updated.  When COMMIT fails in this
+way, the transaction remains active and the COMMIT can be retried later
+after the reader has had a chance to clear.
 
    
 }
 
@@ -251,6 +258,11 @@ COPY [ OR  ] [ .]  FROM The COPY command is available in SQLite version 2.8 and earlier.
+The COPY command has been removed from SQLite version 3.0 due to
+complications in trying to support it in a mixed UTF-8/16 environment.
+
    
+
 
    The COPY command is an extension used to load large amounts of
 data into a table.  It is modeled after a similar command found
 in PostgreSQL.  In fact, the SQLite COPY command is specifically
@@ -290,7 +302,7 @@ CREATE [UNIQUE] INDEX 
 ON [ .]  (  [, ]* )
 [ ON CONFLICT  ]
 } {column-name} {
- [ ASC | DESC ]
+ [ COLLATE ] [ ASC | DESC ]
 }
 
 puts {
@@ -302,6 +314,12 @@ Each column name can be followed by one of the "ASC" or "DESC" keywords
 to indicate sort order, but the sort order is ignored in the current
 implementation.  Sorting is always done in ascending order.
    
 
+
    The COLLATE clause following each column name defines a collating
+sequence used for text entires in that column.  The default collating
+sequence is the collating sequence defined for that column in the
+CREATE TABLE statement.  Or if no collating sequence is otherwise defined,
+the built-in BINARY collating sequence is used.
    
+
 
    There are no arbitrary limits on the number of indices that can be
 attached to a single table, nor on the number of columns in an index.
    
 
@@ -353,7 +371,8 @@ NOT NULL [  ] |
 PRIMARY KEY [] [  ] |
 UNIQUE [  ] |
 CHECK (  ) [  ] |
-DEFAULT 
+DEFAULT  |
+COLLATE 
 } {constraint} {
 PRIMARY KEY (  ) [  ] |
 UNIQUE (  ) [  ] |
@@ -379,6 +398,9 @@ The UNIQUE constraint causes an index to be created on the specified
 columns.  This index must contain unique keys.
 The DEFAULT constraint
 specifies a default value to use when doing an INSERT.
+The COLLATE clause specifies what text collating function to use
+when comparing text entries for the column.  The built-in BINARY
+collating function is used by default.
 
    
 
 
    Specifying a PRIMARY KEY normally just creates a UNIQUE index
@@ -1246,14 +1268,6 @@ is returned it is as an integer.
    
     the default_cache_size 
     pragma to check the cache size permanently.
    • 
 
-
  • PRAGMA count_changes = ON; (1)
-       
    PRAGMA count_changes = OFF;     (0)
    
-    
    When on, the COUNT_CHANGES pragma causes the callback function to
-    be invoked once for each DELETE, INSERT, or UPDATE operation.  The
-    argument is the number of rows that were changed.
    
-    
    This pragma may be removed from future versions of SQLite.
-    Consider using the sqlite_changes() API function instead.
    • 
-
 
  • PRAGMA database_list;
    
     
    For each open database, invoke the callback function once with
     information about that database.  Arguments include the index and 
@@ -1336,30 +1350,12 @@ is returned it is as an integer.
    
     temp_store pragma to change the
     temp_store mode for the current session.
    • 
 
-
-
  • PRAGMA empty_result_callbacks = ON; (1)
-       
    PRAGMA empty_result_callbacks = OFF;     (0)
    
-    
    When on, the EMPTY_RESULT_CALLBACKS pragma causes the callback
-    function to be invoked once for each query that has an empty result
-    set.  The third "argv" parameter to the callback is set to NULL
-    because there is no data to report.  But the second "argc" and
-    fourth "columnNames" parameters are valid and can be used to
-    determine the number and names of the columns that would have been in
-    the result set had the set not been empty.
    • 
-
 
  • PRAGMA foreign_key_list(table-name);
    
     
    For each foreign key that references a column in the argument
     table, invoke the callback function with information about that
     foreign key. The callback function will be invoked once for each
     column in each foreign key.
    • 
 
-
  • PRAGMA full_column_names = ON; (1)
-       
    PRAGMA full_column_names = OFF;     (0)
    
-    
    The column names reported in an SQLite callback are normally just
-    the name of the column itself, except for joins when "TABLE.COLUMN"
-    is used.  But when full_column_names is turned on, column names are
-    always reported as "TABLE.COLUMN" even for simple queries.
    • 
-
 
  • PRAGMA index_info(index-name);
    
     
    For each column that the named index references, invoke the 
     callback function
@@ -1387,39 +1383,6 @@ is returned it is as an integer.
    
     This only works if the library is compiled without the NDEBUG macro.
     
    • 
 
-
-
  • PRAGMA show_datatypes = ON; (1)
-    
    PRAGMA show_datatypes = OFF;     (0)
    
-    
    When turned on, the SHOW_DATATYPES pragma causes extra entries containing
-    the names of datatypes of columns to be
-    appended to the 4th ("columnNames") argument to sqlite_exec()
-    callbacks.  When
-    turned off, the 4th argument to callbacks contains only the column names.
-    The datatype for table columns is taken from the CREATE TABLE statement
-    that defines the table.  Columns with an unspecified datatype have a
-    datatype of "NUMERIC" and the results of expression have a datatype of
-    either "TEXT" or "NUMERIC" depending on the expression.
-    The following chart illustrates the difference for the query
-    "SELECT 'xyzzy', 5, NULL AS empty ":
    
-
-    
    
-    
-        
-    
    show_datatypes=OFFshow_datatypes=ON
    
-       azCol[0] = "xyzzy";
    
-       azCol[1] = "5";
    
-       azCol[2] = "empty";
    
-       azCol[3] = 0;
-        		
-       azCol[0] = "xyzzy";
    
-       azCol[1] = "5";
    
-       azCol[2] = "empty";
    
-       azCol[3] = "TEXT";
    
-       azCol[4] = "NUMERIC";
    
-       azCol[5] = "TEXT";
    
-       azCol[6] = 0;
-    
    • 
-
 
 
  • PRAGMA synchronous;
        
    PRAGMA synchronous = FULL;     (2)
@@ -1513,7 +1476,7 @@ STAR |  . STAR |  [ [AS]  ]
 } {sort-expr-list} {
  [] [,  []]*
 } {sort-order} {
-ASC | DESC
+[ COLLATE  ] [ ASC | DESC ]
 } {compound_op} {
 UNION | UNION ALL | INTERSECT | EXCEPT
 }
@@ -1561,8 +1524,9 @@ The argument to ORDER BY is a list of expressions that are used as the
 key for the sort.  The expressions do not have to be part of the
 result for a simple SELECT, but in a compound SELECT each sort
 expression must exactly match one of the result columns.  Each
-sort expression may be optionally followed by ASC or DESC to specify
-the sort order.
    
+sort expression may be optionally followed by a COLLATE keyword and
+the name of a collating function used for ordering text and/or
+keywords ASC or DESC to specify the sort order.
    
 
 
    The LIMIT clause places an upper bound on the number of rows
 returned in the result.  A negative LIMIT indicates no upper bound.
diff --git a/www/version3.tcl b/www/version3.tcl
new file mode 100644
index 0000000000..1955ca77b9
--- /dev/null
+++ b/www/version3.tcl
@@ -0,0 +1,285 @@
+#!/usr/bin/tclsh
+source common.tcl
+header {SQLite Version 3 Overview}
+puts {
+
    SQLite Version 3 Overview
    
+
+
    
+SQLite version 3.0 introduces important changes to the library, including:
+
    
+
+
      
+
    • A more compact format for database files.
      • 
+
    • Manifest typing and BLOB support.
      • 
+
    • Support for both UTF-8 and UTF-16 text.
      • 
+
    • User-defined text collating sequences.
      • 
+
    • 64-bit ROWIDs.
      • 
+
    • Improved Concurrency.
      • 
+
    
+
+
    
+This document is a quick introduction to the changes for SQLite 3.0
+for users who are already familiar with SQLite version 2.8.
+
    
+
+
    Naming Changes
    
+
+
    
+SQLite version 2.8 will continue to be supported with bug fixes
+for the foreseeable future.  In order to allow SQLite version 2.8
+and SQLite version 3.0 to peacefully coexist, the names of key files
+and APIs in SQLite version 3.0 have been changed to include the
+character "3".  For example, the include file used by C programs
+has been changed from "sqlite.h" to "sqlite3.h".  And the name of
+the shell program used to interact with databases has been changed
+from "sqlite.exe" to "sqlite3.exe".  With these changes, it is possible
+to have both SQLite 2.8 and SQLite 3.0 installed on the same system at
+the same time.  And it is possible for the same C program to link
+against both SQLite 2.8 and SQLite 3.0 at the same time and to use
+both libraries at the same time.
+
    
+
+
    New File Format
    
+
+
    
+The format used by SQLite database files has been completely revised.
+The old version 2.1 format and the new 3.0 format are incompatible with
+one another.  Version 2.8 of SQLite will not read and version 3.0 database
+files and version 3.0 of SQLite will not read a version 2.8 database file.
+
    
+
+
    
+To convert an SQLite 2.8 database into an SQLite 3.0 database, have
+ready the command-line shells for both version 2.8 and 3.0.  Then
+enter a command like the following:
+
    
+
+
    +sqlite OLD.DB .dump | sqlite3 NEW.DB
+
    
+
+
    
+The new database file format uses B+Trees for tables.  In a B+Tree, all
+data is stored in the leaves of the tree instead of in both the leaves and
+the intermediate branch nodes.  The use of B+Trees for tables allows for
+better scalability and the storage larger data fields without the use of
+overflow pages.  Traditional B-Trees are still used for indices.
    
+
+
    
+The new file format also supports variable pages sizes between 512 and
+65536 bytes.  The size of a page is stored in the file header so the
+same library can read databases with different pages sizes, in theory,
+though this feature has not yet been implemented in practice.
+
    
+
+
    
+The new file format omits unused fields from its disk images.  For example,
+indices use only the key part of a B-Tree record and not the data.  So
+for indices, the field that records the length of the data is omitted.
+Integer values such as the length of key and data are stored using
+a variable-length encoding so that only one or two bytes are required to
+store the most common cases but up to 64-bits of information can be encoded
+if needed. 
+Integer and floating point data is stored on the disk in binary rather
+than being converted into ASCII as in SQLite version 2.8.
+These changes taken together result in database files that are typically
+25% to 35% smaller than the equivalent files in SQLite version 2.8.
+
    
+
+
    
+Details of the low-level B-Tree format used in SQLite version 3.0 can
+be found in header comments to the 
+btree.c
+source file.
+
    
+
+
    Manifest Typing and BLOB Support
    
+
+
    
+SQLite version 2.8 will deal with data in various formats internally,
+but when writing to the disk or interacting through its API, SQLite 2.8
+always converts data into ASCII text.  SQLite 3.0, in contrast, exposes 
+its internal data representations to the user and stores binary representations
+to disk when appropriate.  The exposing of non-ASCII representations was
+added in order to support BLOBs.
+
    
+
+
    
+SQLite version 2.8 had the feature that any type of data could be stored
+in any table column regardless of the declared type of that column.  This
+feature is retained in version 3.0, though in a slightly modified form.
+Each table column will store any type of data, though columns have an
+affinity for the format of data defined by their declared datatype.
+When data is inserted into a column, that column will make at attempt
+to convert the data format into the columns declared type.   All SQL
+database engines do this.  The difference is that SQLite 3.0 will 
+still store the data even if a format conversion is not possible.
+
    
+
+
    
+For example, if you have a table column declared to be of type "INTEGER"
+and you try to insert a string, the column will look at the text string
+and see if it looks like a number.  If the string does look like a number
+it is converted into a number and into an integer if the number does not
+have a fractional part, and stored that way.  But if the string is not
+a well-formed number it is still stored as a string.  A column with a
+type of "TEXT" tries to convert numbers into an ASCII-Text representation
+before storing them.  But BLOBs are stored in TEXT columns as BLOBs because
+you cannot in general convert a BLOB into text.
+
    
+
+
    
+In most other SQL database engines the datatype is associated with
+the table column the holds the data - with the data container.
+In SQLite 3.0, the datatype is associated with the data itself, not
+with its container.
+Paul Graham in his book 
+ANSI Common Lisp
+calls this property "Manifest Typing".
+Other writers have other definitions for the term "manifest typing",
+so beware of confusion.  But by whatever name, that is the datatype
+model supported by SQLite 3.0.
+
    
+
+
    
+Additional information about datatypes in SQLite version 3.0 is
+available
+separately.
+
    
+
+
    Support for UTF-8 and UTF-16
    
+
+
    
+The new API for SQLite 3.0 contains routines that accept text as
+both UTF-8 and UTF-16 in the native byte order of the host machine.
+Each database file manages text as either UTF-8, UTF-16BE (big-endian),
+or UTF-16LE (little-endian).  Internally and in the disk file, the
+same text representation is used everywhere.  If the text representation
+specified by the database file (in the file header) does not match
+the text representation required by the interface routines, then text
+is converted on-the-fly.
+Constantly converting text from one representation to another can be
+computationally expensive, so it is suggested that programmers choose a
+single representation and stick with it throughout their application.
+
    
+
+
    
+In the current implementation of SQLite, the SQL parser only works
+with UTF-8 text.  So if you supply UTF-16 text it will be converted.
+This is just an implementation issue and there is nothing to prevent
+future versions of SQLite from parsing UTF-16 encoded SQL natively.
+
    
+
+
    
+When creating new user-defined SQL functions and collating sequences,
+each function or collating sequence can specify it if works with
+UTF-8, UTF-16be, or UTF-16le.  Separate implementations can be registered
+for each encoding.   If an SQL function or collating sequences is required
+but a version for the current text encoding is not available, then 
+the text is automatically converted.  As before, this conversion takes
+computation time, so programmers are advised to pick a single
+encoding and stick with it in order to minimize the amount of unnecessary
+format juggling.
+
    
+
+
    
+SQLite is not particular about the text it receives and is more than
+happen to process text strings that are not normalized or even
+well-formed UTF-8 or UTF-16.  Thus, programmers who want to store
+IS08859 data can do so using the UTF-8 interfaces.  As long as no
+attempts are made to use a UTF-16 collating sequence or SQL function,
+the byte sequence of the text will not be modified in any way.
+
    
+
+
    User-defined Collating Sequences
    
+
+
    
+A collating sequence is just a defined order for text.  When SQLite 3.0
+sorts (or uses a comparison operator like "<" or ">=") the sort order
+is first determined by the data type.
+
    
+
+
      
+
    • NULLs sort first
      • 
+
    • Numeric values sort next in numerical order
      • 
+
    • Text values come after numerics
      • 
+
    • BLOBs sort last
      • 
+
    
+
+
    
+Collating sequences are used for comparing two text strings.
+The collating sequence does not change the ordering of NULLs, numbers,
+or BLOBs, only text.
+
    
+
+
    
+A collating sequence is implemented as a function that takes the
+two strings being compared as inputs and returns negative, zero, or
+positive if the first string is less than, equal to, or greater than
+the first.
+SQLite 3.0 comes with a single built-in collating sequence named "BINARY"
+which is implemented using the memcmp() routine from the standard C library.
+The BINARY collating sequence works well for English text.  For other
+languages or locales, alternative collating sequences may be preferred.
+
    
+
+
    
+The decision of which collating sequence to use is controlled by the
+COLLATE clause in SQL.  A COLLATE clause can occur on a table definition,
+to define a default collating sequence to a table column, or on field
+of an index, or in the ORDER BY clause of a SELECT statement.
+Planned enhancements to SQLite are to include standard CAST() syntax
+to allow the collating sequence of an expression to be defined.
+
    
+
+
    64-bit ROWIDs
    
+
+
    
+Every row of a table has a unique rowid.
+If the table defines a column with the type "INTEGER PRIMARY KEY" then that
+column becomes an alias for the rowid.  But with or without an INTEGER PRIMARY
+KEY column, every row still has a rowid.
+
    
+
+
    
+In SQLite version 3.0, the rowid is a 64-bit signed integer.
+This is an expansion of SQLite version 2.8 which only permitted
+rowids of 32-bits.
+
    
+
+
    
+To minimize storage space, the 64-bit rowid is stored as a variable length
+integer.  Rowids between 0 and 127 use only a single byte.  
+Rowids between 0 and 16383 use just 2 bytes.  Up to 2097152 uses three
+bytes.  And so forth.  Negative rowids are allowed but they always use
+nine bytes of storage and so their use is discouraged.  When rowids
+are generated automatically by SQLite, they will always be non-negative.
+
    
+
+
    Improved Concurrency
    
+
+
    
+SQLite version 2.8 allowed multiple simultaneous readers or a single
+writer but not both.  SQLite version 3.0 allows one process to begin
+writing the database while other processes continue to read.  The
+writer must still obtain an exclusive lock on the database for a brief
+interval in order to commit its changes, but the exclusive lock is no
+longer required for the entire write operation.
+A more detailed report on the locking
+behavior of SQLite version 3.0 is available separately.
+
    
+
+
    
+A limited form of table-level locking is now also available in SQLite.
+If each table is stored in a separate database file, those separate
+files can be attached to the main database (using the ATTACH command)
+and the combined databases will function as one.  But locks will only
+be acquired on individual files as needed.  So if you redefine "database"
+to mean two or more database files, then it is entirely possible for
+two processes to be writing to the same database at the same time.
+To further support this capability, commits of transactions involving
+two or more ATTACHed database are now atomic.
+
    
+
+}
+footer {$Id: version3.tcl,v 1.1 2004/06/17 19:04:17 drh Exp $}