Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Fix typos in capi3.tcl (CVS 1618) |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA1: |
9e0e530f10bf70996471650496173dee |
User & Date: | danielk1977 2004-06-18 11:34:09.000 |
Context
2004-06-18
| ||
12:29 | Version 3.0.0 (ALPHA) (CVS 1619) (check-in: 8b409aaae4 user: drh tags: trunk) | |
11:34 | Fix typos in capi3.tcl (CVS 1618) (check-in: 9e0e530f10 user: danielk1977 tags: trunk) | |
11:29 | Update the Makefile.in, version number, change log, etc for the 3.0.0 release. (CVS 1617) (check-in: 917391e05e user: drh tags: trunk) | |
Changes
Changes to www/capi3.tcl.
|
| | | < | < | | | | | | | | < | < | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 | set rcsid {$Id: capi3.tcl,v 1.5 2004/06/18 11:34:09 danielk1977 Exp $} source common.tcl header {C/C++ Interface For SQLite Version 3} puts { <h2>C/C++ Interface For SQLite Version 3</h2> <h3>1.0 Overview</h3> <p> SQLite version 3.0 is a new version of SQLite, derived from the SQLite 2.8.13 code base, but with an incompatible file format and API. SQLite version 3.0 was created to answer demand for the following features: </p> <ul> <li>Support for UTF-16.</li> <li>User-definable text collating sequences.</li> <li>The ability to store BLOBs in indexed columns.</li> </ul> <p> It was necessary to move to version 3.0 to implement these features because each requires incompatible changes to the database file format. Other incompatible changes, such as a cleanup of the API, were introduced at the same time under the theory that it is best to get your incompatible changes out of the way all at once. </p> <p> The API for version 3.0 is similar to the version 2.X API, but with some important changes. Most noticeably, the "<tt>sqlite_</tt>" prefix that occurs on the beginning of all API functions and data structures are changed to "<tt>sqlite3_</tt>". This avoids confusion between the two APIs and allows linking against both SQLite 2.X and SQLite 3.0 at the same time. </p> <p> There is no agreement on what the C datatype for a UTF-16 string should be. Therefore, SQLite uses a generic type of void* to refer to UTF-16 strings. Client software can cast the void* to whatever datatype is appropriate for their system. </p> <h3>2.0 C/C++ Interface</h3> <p> The API for SQLite 3.0 three includes 83 separate functions in addition |
︙ | ︙ | |||
88 89 90 91 92 93 94 | <p> The sqlite3_open() routine returns an integer error code rather than 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 | | | | | | | | 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 | <p> The sqlite3_open() routine returns an integer error code rather than 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() sets the internal text representation to UTF-16 whereas sqlite3_open() sets the text representation to UTF-8. </p> <p> 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. </p> <p> The sqlite3_errcode() routine returns a result code for the most recent major API call. sqlite3_errmsg() returns an English-language text error message for the most recent error. The error message is represented in UTF-8 and will be ephemeral - it could disappear on the next call to any SQLite API function. sqlite3_errmsg16() works like sqlite3_errmsg() except that it returns the error message represented as UTF-16 in host native byte order. </p> <p> The error codes for SQLite version 3 are unchanged from version2. |
︙ | ︙ | |||
174 175 176 177 178 179 180 | int sqlite3_prepare16(sqlite3*, const void*, int, sqlite3_stmt**, const void**); int sqlite3_finalize(sqlite3_stmt*); int sqlite3_reset(sqlite3_stmt*); </pre></blockquote> <p> The sqlite3_prepare interface compiles a single SQL statement into byte code | | | | 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 | int sqlite3_prepare16(sqlite3*, const void*, int, sqlite3_stmt**, const void**); int sqlite3_finalize(sqlite3_stmt*); int sqlite3_reset(sqlite3_stmt*); </pre></blockquote> <p> 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. </p> <p> 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. |
︙ | ︙ |