to implement the PRIMARY KEY or UNIQUE constraints) the <b>sql</b> field  is NULL.</p>  <p>The SQLITE_MASTER table is read-only.  You cannot change this table  using UPDATE, INSERT, or DELETE.  The table is automatically updated by  CREATE TABLE, CREATE INDEX, DROP TABLE, and DROP INDEX commands.</p>  <p>Temporary tables do not appear in the SQLITE_MASTER table.  Temporary  tables and their indices and triggers occur in another special table  named SQLITE_TEMP_MASTER.  SQLITE_TEMP_MASTER works just like SQLITE_MASTER  except that it is only visible to the application that created the   temporary tables.  To get a list of all tables, both permanent and  temporary, one can use a command similar to the following:<blockquote><pre>SELECT name FROM    (SELECT * FROM sqlite_master UNION ALL    SELECT * FROM sqlite_temp_master)WHERE type='table'ORDER BY name</pre></blockquote>}faq {  Are there any known size limits to SQLite databases?} {  <p>A database is limited in size to 2 tibibytes (2<sup>41</sup> bytes).  That is a theoretical limitation.  In practice, you should try to keep  your SQLite databases below 100 gigabytes to avoid performance problems.  If you need to store 100 gigabytes or more in a database, consider using  an enterprise database engine which is designed for that purpose.</p>  <p>The theoretical limit on the number of rows in a table is  2<sup>64</sup>-1, though obviously you will run into the file size  limitation prior to reaching the row limit.  A single row can hold  up to 2<sup>30</sup> bytes of data in the current implementation.  The  underlying file format supports row sizes up to about 2<sup>62</sup> bytes.  </p>  <p>There are probably limits on the number of tables or indices or  the number of columns in a table or index, but nobody is sure what  those limits are.  In practice, SQLite must read and parse the original  SQL of all table and index declarations everytime a new database file  is opened, so for the best performance of  <a href="capi3ref.html#sqlite3_open">sqlite3_open()</a> it is best  to keep down the number of declared tables.   Likewise, though there  is no limit on the number of columns in a table, more than a few hundred  seems extreme.  Only the first 31 columns of a table are candidates for  certain optimizations.  You can put as many columns in an index as you like  but indexes with more than 30 columns will not be used to optimize queries.  </p>  <p>The names of tables, indices, view, triggers, and columns can be  as long as desired.  However, the names of SQL functions (as created  by the   <a href="capi3ref.html#sqlite3_create_function">sqlite3_create_function()</a>  API) may not exceed 255 characters in length.</p>}faq {  What is the maximum size of a VARCHAR in SQLite?} {  <p>SQLite does not enforce the length of a VARCHAR.  You can declare  a VARCHAR(10) and SQLite will be happy to let you put 500 characters  in it.  And it will keep all 500 characters intact - it never truncates.  </p>}faq {  Does SQLite support a BLOB type?} {  <p>SQLite versions 3.0 and later allow you to store BLOB data in any   column, even columns that are declared to hold some other type.</p>}faq {  How do I add or delete columns from an existing table in SQLite.} {  <p>SQLite has limited   <a href="lang_altertable.html">ALTER TABLE</a> support that you can  use to add a column to the end of a table or to change the name of  a table.    If you what make more complex changes the structure of a table,  you will have to recreate the  table.  You can save existing data to a temporary table, drop the  old table, create the new table, then copy the data back in from  the temporary table.</p>  <p>For example, suppose you have a table named "t1" with columns  names "a", "b", and "c" and that you want to delete column "c" from  this table.  The following steps illustrate how this could be done:  </p>  <blockquote><pre>BEGIN TRANSACTION;CREATE TEMPORARY TABLE t1_backup(a,b);INSERT INTO t1_backup SELECT a,b FROM t1;DROP TABLE t1;CREATE TABLE t1(a,b);INSERT INTO t1 SELECT a,b FROM t1_backup;DROP TABLE t1_backup;COMMIT;</pre></blockquote>}faq {  I deleted a lot of data but the database file did not get any  smaller.  Is this a bug?} {  <p>No.  When you delete information from an SQLite database, the  unused disk space is added to an internal "free-list" and is reused  the next time you insert data.  The disk space is not lost.  But  neither is it returned to the operating system.</p>  <p>If you delete a lot of data and want to shrink the database file,  run the <a href="lang_vacuum.html">VACUUM</a> command.  VACUUM will reconstruct  the database from scratch.  This will leave the database with an empty  free-list and a file that is minimal in size.  Note, however, that the  VACUUM can take some time to run (around a half second per megabyte  on the Linux box where SQLite is developed) and it can use up to twice  as much temporary disk space as the original file while it is running.  </p>  <p>As of SQLite version 3.1, an alternative to using the VACUUM command  is auto-vacuum mode, enabled using the   <a href="pragma.html#pragma_auto_vacuum">auto_vacuum pragma</a>.</p>}faq {  Can I use SQLite in my commercial product without paying royalties?} {  <p>Yes.  SQLite is in the   <a href="copyright.html">public domain</a>.  No claim of ownership is made  to any part of the code.  You can do anything you want with it.</p>}faq {  How do I use a string literal that contains an embedded single-quote (')  character?} {  <p>The SQL standard specifies that single-quotes in strings are escaped  by putting two single quotes in a row.  SQL works like the Pascal programming  language in the regard.  SQLite follows this standard.  Example:  </p>  <blockquote><pre>    INSERT INTO xyz VALUES('5 O''clock');  </pre></blockquote>}faq {What is an SQLITE_SCHEMA error, and why am I getting one?} {  <p>An SQLITE_SCHEMA error is returned when a   prepared SQL statement is no longer valid and cannot be executed.  When this occurs, the statement must be recompiled from SQL using   the   <a href="capi3ref.html#sqlite3_prepare">sqlite3_prepare()</a> API.  In SQLite version 3, an SQLITE_SCHEMA error can  only occur when using the   <a href="capi3ref.html#sqlite3_prepare">sqlite3_prepare()</a>/<a  href="capi3ref.html#sqlite3_step">sqlite3_step()</a>/<a  href="capi3ref.html#sqlite3_finalize">sqlite3_finalize()</a>  API to execute SQL, not when using the  <a href="capi3ref.html#sqlite3_exec">sqlite3_exec()</a>. This was not  the case in version 2.</p>  <p>The most common reason for a prepared statement to become invalid  is that the schema of the database was modified after the SQL was   prepared (possibly by another process).  The other reasons this can   happen are:</p>   <ul>  <li>A database was <a href="lang_detach.html">DETACH</a>ed.  <li>The database was <a href="lang_vacuum.html">VACUUM</a>ed  <li>A user-function definition was deleted or changed.  <li>A collation sequence definition was deleted or changed.  <li>The authorization function was changed.  </ul>  <p>In all cases, the solution is to recompile the statement from SQL  and attempt to execute it again. Because a prepared statement can be  invalidated by another process changing the database schema, all code  that uses the  <a href="capi3ref.html#sqlite3_prepare">sqlite3_prepare()</a>/<a  href="capi3ref.html#sqlite3_step">sqlite3_step()</a>/<a  href="capi3ref.html#sqlite3_finalize">sqlite3_finalize()</a>  API should be prepared to handle SQLITE_SCHEMA errors. An example  of one approach to this follows:</p>  <blockquote><pre>    int rc;    sqlite3_stmt *pStmt;    char zSql[] = "SELECT .....";    do {      /* Compile the statement from SQL. Assume success. */      sqlite3_prepare(pDb, zSql, -1, &pStmt, 0);      while( SQLITE_ROW==sqlite3_step(pStmt) ){        /* Do something with the row of available data */      }      /* Finalize the statement. If an SQLITE_SCHEMA error has      ** occured, then the above call to sqlite3_step() will have      ** returned SQLITE_ERROR. sqlite3_finalize() will return      ** SQLITE_SCHEMA. In this case the loop will execute again.      */      rc = sqlite3_finalize(pStmt);    } while( rc==SQLITE_SCHEMA );      </pre></blockquote>}faq {Why does ROUND(9.95,1)  return 9.9 instead of 10.0?     Shouldn't 9.95 round up?} {  <p>SQLite uses binary arithmetic and in binary, there is no  way to write 9.95 in a finite number of bits.  The closest to  you can get to 9.95 in a 64-bit IEEE float (which is what  SQLite uses) is 9.949999999999999289457264239899814128875732421875.  So when you type "9.95", SQLite really understands the number to be  the much longer value shown above.  And that value rounds down.</p>  <p>This kind of problem comes up all the time when dealing with  floating point binary numbers.  The general rule to remember is  that most fractional numbers that have a finite representation in decimal  (a.k.a "base-10")  do not have a finite representation in binary (a.k.a "base-2").  And so they are  approximated using the closest binary number available.  That  approximation is usually very close, but it will be slightly off  and in some cases can cause your results to be a little different  from what you might expect.</p>}# End of questions and answers.#############puts {<h2>Frequently Asked Questions</h2>}# puts {<DL COMPACT>}# for {set i 1} {$i<$cnt} {incr i} {#   puts "  <DT><A HREF=\"#q$i\">($i)</A></DT>"#   puts "  <DD>[lindex $faq($i) 0]</DD>"# }# puts {</DL>}puts {<OL>}for {set i 1} {$i<$cnt} {incr i} {  puts "<li><a href=\"#q$i\">[lindex $faq($i) 0]</a></li>"}puts {</OL>}for {set i 1} {$i<$cnt} {incr i} {  puts "<A NAME=\"q$i\"><HR />"  puts "<P><B>($i) [lindex $faq($i) 0]</B></P>\n"  puts "<BLOCKQUOTE>[lindex $faq($i) 1]</BLOCKQUOTE></LI>\n"}puts {</OL>}footer $rcsid