SQLite

  regsub -all {[Tt]icket #(\d+)} $desc \
      {<a href="http://www.sqlite.org/cvstrac/tktview?tn=\1">\0</a>} desc
  puts "<DD><P><UL>$desc</UL></P>"
  puts "</DD>"
}


chng {2007 Sep 3 (3.5.0 beta)} {
<li>Redesign the OS interface layer.  See
    <a href="34to35.html">34to35.html</a> for details.
    <font color="red">*** Potentially incompatible change ***</font>
<li>The <a href="capi3ref.html#sqlite3_release_memory">
    sqlite3_release_memory()</a>,
    <a href="capi3ref.html#sqlite3_soft_heap_limit">
    sqlite3_soft_heap_limit()</a>,

#
# Run this script to generated a faq.html output file
#
set rcsid {$Id: faq.tcl,v 1.39 2007/08/03 08:18:45 danielk1977 Exp $}
source common.tcl
header {SQLite Frequently Asked Questions</title>}

set cnt 1
proc faq {question answer} {
  set ::faq($::cnt) [list [string trim $question] [string trim $answer]]
  incr ::cnt

  API functions.</p>
}

faq {
  Is SQLite threadsafe?
} {
  <p>Yes.  Sometimes.  In order to be thread-safe, SQLite must be compiled
  with the THREADSAFE preprocessor macro set to 1.  In the default
  distribution, the windows binaries are compiled to be threadsafe but
  the linux binaries are not.  If you want to change this, you'll have to
  recompile.</p>

  <p>"Threadsafe" in the previous paragraph means that two or more threads
  can run SQLite at the same time on different "<b>sqlite3</b>" structures
  returned from separate calls to 
  <a href="capi3ref.html#sqlite3_open">sqlite3_open()</a>.  It is never safe
  to use the same <b>sqlite3</b> structure pointer in two
  or more threads.</p>

  <p>Prior to version 3.3.1,
  an <b>sqlite3</b> structure could only be used in the same thread
  that called <a href="capi3ref.html#sqlite3_open">sqlite3_open</a>
  to create it.
  You could not open a
  database in one thread then pass the handle off to another thread for

  <p>The restriction on moving database connections across threads
  was relaxed somewhat in version 3.3.1.  With that and subsequent
  versions, it is safe to move a connection handle across threads
  as long as the connection is not holding any fcntl() locks.  You
  can safely assume that no locks are being held if no
  transaction is pending and all statements have been finalized.</p>

  <p>If you turn on
  <a href="capi3ref.html#sqlite3_enable_shared_cache">shared cache</a>
  mode or if you compile with the -DSQLITE_ENABLE_MEMORY_MANAGEMENT=1
  option, then you can never move an <b>sqlite3</b> pointer across
  threads.  The <b>sqlite3</b> pointer must only be used in the same
  thread in which it was created by 
  <a href="capi3ref.html#sqlite3_open">sqlite3_open()</a>.  If you
  break the rules and use an <b>sqlite3</b> handle in more than one 
  thread under these circumstances you will likely corrupt some
  internal data structures, resulting in a crash.</p>

  <p>Under UNIX, you should not carry an open SQLite database across
  a fork() system call into the child process.  Problems will result
  if you do.</p>
}

faq {
  How do I list all tables/indices contained in an SQLite database

proc newsitem {date title text} {
  puts "<h3>$date - $title</h3>"
  regsub -all "\n( *\n)+" $text "</p>\n\n<p>" txt
  puts "<p>$txt</p>"
  puts "<hr width=\"50%\">"
}

newsitem {2007-Sep-3} {Version 3.5.0 beta} {
  The OS interface layer and the memory allocation subsystems in
  SQLite have been reimplemented.  The published API is largely unchanged
  but the (unpublished) OS interface has been modified extensively.  
  Application that implement their own OS interface will require
  modification.  See
  <a href="34to35.html">34to35.html</a> for details.<p>

  This is a large change approximately 1 line of count of out 10 was
  modified.  We are calling this first release "beta" in order to give
  the user community time to test and evaluate the changes before we
  freeze the new design.
}

newsitem {2007-Aug-13} {Version 3.4.2} {
  While stress-testing the 
  <a href="capi3ref.html#sqlite3_soft_heap_limit">soft_heap_limit</a>

  database corruption</a>.  The bug was introduced in version 
  <a href="changes.html#version_3_3_14">3.3.14</a>.
  Upgrading is recommended for all users.  Also included are a slew of
  other more routine
  <a href="changes.html#version_3_4_1">enhancements and bug fixes</a>.
}

newsitem {2007-Jun-18} {Version 3.4.0} {
  This release fixes two separate bugs either of which 
  can lead to database corruption.  Upgrading
  is strongly recommended.  If you must continue using an older version
  of SQLite, please at least read about how to avoid these bugs
  at
  <a href="http://www.sqlite.org/cvstrac/wiki?p=CorruptionFollowingBusyError">
  CorruptionFollowingBusyError</a> and
  <a href="http://www.sqlite.org/cvstrac/tktview?tn=2418">ticket #2418</a>
  <p>
  This release also adds explicit <a href="limits.html">limits</a> on the
  sizes and quantities of things SQLite will handle.  The new limits might
  causes compatibility problems for existing applications that
  use excessively large strings, BLOBs, tables, or SQL statements. 
  The new limits can be increased at compile-time to work around any problems
  that arise.  Nevertheless, the version number of this release is
  3.4.0 instead of 3.3.18 in order to call attention to the possible
  incompatibility.
  </p>
  There are also new features, including
  <a href="capi3ref.html#sqlite3_blob_open">incremental BLOB I/O</a> and
  <a href="pragma.html#pragma_incremental_vacuum">incremental vacuum</a>.
  See the <a href="changes.html#version_3_4_0">change log</a> 
  for additional information.
}

puts {
<p align="right"><a href="oldnews.html">Old news...</a></p>
</td></tr></table>
}
footer {$Id: index.tcl,v 1.160 2007/09/03 20:32:46 drh Exp $}

#!/usr/bin/tclsh
source common.tcl
header {SQLite Older News}

proc newsitem {date title text} {
  puts "<h3>$date - $title</h3>"
  regsub -all "\n( *\n)+" $text "</p>\n\n<p>" txt
  puts "<p>$txt</p>"
  puts "<hr width=\"50%\">"
}



























newsitem {2007-Apr-25} {Version 3.3.17} {
  This version fixes a bug in the forwards-compatibility logic of SQLite
  that was causing a database to become unreadable when it should have
  been read-only.  Upgrade from 3.3.16 only if you plan to deploy into
  a product that might need to be upgraded in the future.  For day to day
  use, it probably does not matter.

  changes to both the C-language API and the underlying file format
  that will enable SQLite to better support internationalization.
  The first beta is schedule for release on 2004-July-01.

  Plans are to continue to support SQLite version 2.8 with
  bug fixes.  But all new development will occur in version 3.0.
}
footer {$Id: oldnews.tcl,v 1.22 2007/08/13 16:15:29 drh Exp $}