Documentation Source Text

Check-in [0ca8a50964]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Change fileformat.in to use Tcl instead of javascript for toc generation etc..
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 0ca8a50964a39dc2cde2491bf7d50d651f31b778
User & Date: dan 2009-02-05 19:45:19
Context
2009-02-10
13:40
Minor edits to the backup application note. Integrate the same into the other documents. check-in: d2614c5467 user: drh tags: trunk
2009-02-05
19:45
Change fileformat.in to use Tcl instead of javascript for toc generation etc.. check-in: 0ca8a50964 user: dan tags: trunk
19:43
Add a page with some backup API examples. check-in: 0c996cb98b user: dan tags: trunk
Changes
Hide Diffs Side-by-Side Diffs Ignore Whitespace Patch

Changes to pages/fileformat.in.

     1      1   <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
     2      2   
     3      3   <html>
     4      4   <head>
     5      5     <link type="text/css" rel="stylesheet" href="images/fileformat/rtdocs.css">
     6         -  <script type="text/javascript" src=images/fileformat/rtdocs.js></script>
     7      6   </head>
     8      7   <body>
     9      8   
    10      9   <div id=document_title>SQLite Database File Format</div>
    11     10   <div id=toc_header>Table Of Contents</div>
    12         -<div id=toc>
    13         -  <b>Javascript is required for some features of this document, including 
    14         -     table of contents, figure numbering and internal references (section
    15         -     numbers and hyper-links.
    16         -  </b>
    17         -</div>
    18         -<!-- End of standard rt docs header -->
    19     11   
    20     12   <tcl>
    21     13   ###############################################################################
    22     14   # The actual text of requirments is stored in ../req/hlr30000.txt.  During
    23     15   # the process in which this document is converted into HTML, TCL script runs
    24     16   # and imports requirements from that file over into this file whenever you
    25     17   # see:
    26     18   #            <t*l>fileformat_import_requirement H00000</t*l>
    27     19   #
    28     20   unset -nocomplain ffreq
    29     21   hd_read_requirement_file $::DOC/req/hlr30000.txt ffreq
    30     22   proc fileformat_import_requirement {reqid} {
    31         -  hd_resolve [lindex $::ffreq($reqid) 1]
           23  +  return [lindex $::ffreq($reqid) 1]
    32     24   }
    33     25   ###############################################################################
    34         -</tcl>
    35         -
    36         -<h1>Document Overview</h1>
    37         -
    38         -  <h2>Scope and Purpose</h2>
           26  +
           27  +catch { array unset ::SectionNumbers }
           28  +set ::SectionNumbers(1) 0
           29  +set ::SectionNumbers(2) 0
           30  +set ::SectionNumbers(3) 0
           31  +set ::SectionNumbers(fig) 0
           32  +catch { set TOC "" }
           33  +catch { array unset ::References }
           34  +
           35  +
           36  +proc H {iLevel zTitle {zName ""}} {
           37  +
           38  +  set zNumber ""
           39  +  for {set i 1} {$i <= 4} {incr i} {
           40  +    if {$i < $iLevel} {
           41  +      append zNumber "$::SectionNumbers($i)."
           42  +    }
           43  +    if {$i == $iLevel} {
           44  +      append zNumber "[incr ::SectionNumbers($i)]."
           45  +    }
           46  +    if {$i > $iLevel} {
           47  +      set ::SectionNumbers($i) 0
           48  +    }
           49  +  }
           50  +  set zNumber [string range $zNumber 0 end-1]
           51  +
           52  +  if {$zName == ""} {
           53  +    set zName [string range "section_[string map {. _} $zNumber]" 0 end-1]
           54  +  } else {
           55  +    set ::References($zName) [list $zNumber $zTitle]
           56  +  }
           57  +
           58  +  append ::TOC [subst {
           59  +    <div style="margin-left:[expr $iLevel*6]ex">
           60  +    <a href="#$zName">${zNumber}. $zTitle</a>
           61  +    </a></div>
           62  +  }]
           63  +
           64  +  return "<h$iLevel id=\"$zName\">$zNumber $zTitle</h$iLevel>\n"
           65  +}
           66  +proc h1 {args} {uplevel H 1 $args}
           67  +proc h2 {args} {uplevel H 2 $args}
           68  +proc h3 {args} {uplevel H 3 $args}
           69  +proc h4 {args} {uplevel H 4 $args}
           70  +
           71  +proc Figure {zImage zName zCaption} {
           72  +  incr ::SectionNumbers(fig)
           73  +  set ::References($zName) [list $::SectionNumbers(fig) $zCaption]
           74  +  subst {
           75  +      <center>
           76  +      <a name="$zName"></a>
           77  +      <img src="images/fileformat/$zImage">
           78  +      <p><i>Figure $::SectionNumbers(fig) - $zCaption</i>
           79  +      </center>
           80  +  }
           81  +}
           82  +
           83  +proc FixReferences {body} {
           84  +  foreach {key value} [array get ::References] {
           85  +    foreach {zNumber zTitle} $value {}
           86  +    lappend l <cite>$key</cite> "<cite><a href=\"#$key\" title=\"$zTitle\">$zNumber</a></cite>"
           87  +  }
           88  +  string map $l $body
           89  +}
           90  +
           91  +proc Table {} {
           92  +  set ::Stripe 1
           93  +  return "<table class=striped>"
           94  +}
           95  +proc Tr {} {
           96  +  set ::Stripe [expr {($::Stripe+1)%2}]
           97  +  if {$::Stripe} {
           98  +    return "<tr style=\"background-color:#DDDDDD\">"
           99  +  } else {
          100  +    return "<tr>"
          101  +  }
          102  +}
          103  +
          104  +set body [subst -novariables {
          105  +
          106  +[h1 "Document Overview"]
          107  +
          108  +  [h2 "Scope and Purpose"]
    39    109   
    40    110     <p>
    41    111       This document is designed to serve two purposes:
    42    112     <ul>
    43    113       <li>to provide an engineering guide to the file format used by SQLite, and
    44    114   
    45    115       <li>to provide system requirements specifying the behaviour of the SQLite
................................................................................
    64    134       may be achieved using SQLite are dealt with elsewhere.
    65    135     <p class=todo>
    66    136       Add references to the documents that do describe these things. One other
    67    137       document will concentrate on the pager module and the way it uses the VFS
    68    138       interface to safely create and update database files.  The other will be
    69    139       the document that describes the supported SQL language and capabilities.
    70    140   
    71         -  <h2>Document and Requirements Organization</h2>
          141  +  [h2 "Document and Requirements Organization"]
    72    142       <p>
    73    143         Section <cite>sqlite_database_files</cite> contains simple 
    74    144         requirements describing the relationship between SQLite and the
    75    145         definition of a <i>well-formed SQLite database file</i>.
    76    146       <p>
    77    147         Section <cite>database_file_format</cite> describes the various fields
    78    148         and sub-structures that make up the SQLite database file format.
................................................................................
    79    149   <!--
    80    150       <p>
    81    151         Section <cite>database_file_manipulation</cite> describes the way in
    82    152         which these fields and data structures are created, initialized and
    83    153         updated.  
    84    154   -->
    85    155   
    86         -  <h2>Glossary</h2>
          156  +  [h2 "Glossary"]
    87    157       <table id=glossary>
    88    158         <tr><td>Auto-vacuum last root-page<td>
    89    159   	A page number stored as 32-bit integer at byte offset 52 of the
    90    160           database file header (see section <cite>file_header</cite>). In
    91    161           an auto-vacuum database, this is the numerically largest 
    92    162   	<i>root-page</i> number in the database. Additionally, all pages that
    93    163   	occur before this page in the database are either B-Tree <i>root
................................................................................
   278    348           on the precise value being stored.
   279    349   
   280    350         <tr><td>Well formed database file <td>
   281    351           An SQLite database file that meets all the criteria laid out in
   282    352           section <cite>database_file_format</cite> of this document.
   283    353       </table>
   284    354   
   285         -<h1 id=sqlite_database_files>SQLite Database Files</h1>
          355  +[h1 "SQLite Database Files" sqlite_database_files]
   286    356    
   287    357     <p>
   288    358       The bulk of this document, section <cite>database_file_format</cite>,
   289    359       contains the definition of a <i>well-formed SQLite database file</i>.
   290    360       SQLite is required to create database files that meet this definition.
   291    361   
   292    362     <p class=req id=H30010>
   293         -          <tcl>fileformat_import_requirement H30010</tcl>
          363  +          [fileformat_import_requirement H30010]
   294    364   
   295    365     <p>
   296    366       Additionally, the database file should contain a serialized version
   297    367       of the logical database produced by the transaction. For all but the
   298    368       most trivial logical databases, there are many possible serial 
   299    369       representations.
   300    370   
   301    371     <p class=req id=H30020>
   302         -          <tcl>fileformat_import_requirement H30020</tcl>
          372  +          [fileformat_import_requirement H30020]
   303    373   
   304    374   <!--
   305    375     <p>
   306    376       Section <cite>database_file_manipulation</cite> contains requirements
   307    377       describing in more detail the way in which SQLite manipulates the
   308    378       fields and data structures described in section
   309    379       <cite>database_file_format</cite> under various circumstances. These
   310    380       requirements are to a certain extent derived from the requirements 
   311    381       in this section.
   312    382   -->
   313    383     
   314    384   
   315         -<h1 id=database_file_format>Database File Format Details</h1>
          385  +[h1 "Database File Format Details" database_file_format]
   316    386   
   317    387     <p>
   318    388       This section describes the various fields and sub-structures that make up
   319    389       the format used by SQLite to serialize a logical SQL database. 
   320    390     <p>
   321    391       This section does not contain requirements governing the behaviour of any
   322    392       software system. Instead, along with the plain language description of the
................................................................................
   350    420       are true. <span class=todo>mention the requirements numbering scheme
   351    421       here.</span> A software system that wishes to interoperate with other
   352    422       systems using the SQLite database file format should only ever
   353    423       output well-formed SQLite databases. In the case of SQLite itself,
   354    424       the system should ensure that the database file is well-formed at
   355    425       the conclusion of each database transaction.
   356    426   
   357         -  <h2 id="fileformat_overview">File Format Overview</h2>
          427  +  [h2 "File Format Overview" "fileformat_overview"]
   358    428       <p>
   359    429         A B-Tree is a data structure designed for offline storage of a set of
   360    430         unique key values. It is structured so as to support fast querying 
   361    431         for a single key or range of keys. As implemented in SQLite, each
   362    432         entry may be associated with a blob of data that is not part of the
   363    433         key. For the canonical introduction to the B-Tree and its variants, 
   364    434         refer to reference <cite>ref_comer_btree</cite>. The B-Tree 
................................................................................
   415    485         ...</pre>
   416    486       <p>
   417    487         Creates a database file containing three B-Tree structures: one table
   418    488         B-Tree to store the <i>sqlite_master</i> table, one table B-Tree to 
   419    489         store table "t1", and one index B-Tree to store index "i1". The
   420    490         B-Tree structures created for the user table and index are populated
   421    491         as shown in figure <cite>figure_examplepop</cite>.
   422         -      <center><img src="images/fileformat/examplepop.gif">
   423         -      <p><i>Figure <span class=fig id=figure_examplepop></span> - Example B-Tree Data.</i>
   424         -      </center>
   425    492   
   426         -  <h2>Global Structure</h2>
          493  +      [Figure examplepop.gif figure_examplepop "Example B-Tree Data"]
          494  +
          495  +  [h2 "Global Structure"]
   427    496       <p>
   428    497         The following sections and sub-sections describe precisely the format
   429    498         used to house the B-Tree structures within an SQLite database file.
   430    499   
   431         -    <h3 id="file_header">File Header</h3>
          500  +    [h3 "File Header" "file_header"]
   432    501         <p>
   433    502           Each SQLite database file begins with a 100-byte header. The header
   434    503           file consists of a well known 16-byte sequence followed by a series of
   435    504           1, 2 and 4 byte unsigned integers. All integers in the file header (as
   436    505           well as the rest of the database file) are stored in big-endian format.
   437    506           
   438    507         <p>
................................................................................
   445    514           Interpreted as UTF-8 encoded text, this byte sequence corresponds 
   446    515           to the string "SQLite format 3" followed by a nul-terminator byte.
   447    516   
   448    517         <p>
   449    518           The 1, 2 and 4 byte unsigned integers that make up the rest of the
   450    519           database file header are described in the following table.
   451    520   
   452         -      <table class=striped>
   453         -        <tr><th>Byte Range <th>Byte Size <th width=100%>Description
   454         -        <tr><td>16..17 <td>2<td>
          521  +      [Table]
          522  +        [Tr]<th>Byte Range <th>Byte Size <th width=100%>Description
          523  +        [Tr]<td>16..17 <td>2<td>
   455    524               Database page size in bytes. See section 
   456    525               <cite>pages_and_page_types</cite> for details.
   457    526   
   458         -        <tr><td>18     <td>1<td>
          527  +        [Tr]<td>18     <td>1<td>
   459    528               <p style="margin-top:0">
   460    529               File-format "write version". Currently, this field
   461    530               is always set to 1. If a value greater than 1 is read by SQLite,
   462    531               then the library will only open the file for read-only access.
   463    532   
   464    533               <p style="margin-bottom:0">
   465    534               This field and the next one are intended to be used for 
................................................................................
   466    535               forwards compatibility, should the need ever arise. If in the
   467    536               future a version of SQLite is created that uses a file format
   468    537               that may be safely read but not written by older versions of
   469    538               SQLite, then this field will be set to a value greater than 1
   470    539               to prevent older SQLite versions from writing to a file that
   471    540               uses the new format. 
   472    541   
   473         -        <tr><td>19     <td>1<td>
          542  +        [Tr]<td>19     <td>1<td>
   474    543               <p style="margin-top:0">
   475    544                File-format "read version". Currently, this 
   476    545               field is always set to 1. If a value greater than 1 is read 
   477    546               by SQLite, then the library will refuse to open the database 
   478    547   
   479    548               <p style="margin-bottom:0">
   480    549               Like the "write version" described above, this field exists
   481    550               to facilitate some degree of forwards compatibility, in case
   482    551               it is ever required. If a version of SQLite created in the 
   483    552               future uses a file format that may not be safely read by older
   484    553               SQLite versions, then this field will be set to a value greater
   485    554               than 1.
   486    555   
   487         -        <tr><td>20     <td>1<td>
          556  +        [Tr]<td>20     <td>1<td>
   488    557               Number of bytes of unused space at the end of each database
   489    558               page. Usually this field is set to 0. If it is non-zero, then 
   490    559               it contains the number of bytes that are left unused at the
   491    560               end of every database page (see section
   492    561               <cite>pages_and_page_types</cite> for a description of a
   493    562               database page).
   494    563   
   495         -        <tr><td>21     <td>1<td>
          564  +        [Tr]<td>21     <td>1<td>
   496    565                Maximum fraction of an index tree page to use for 
   497    566               embedded content. This value is used to determine the maximum
   498    567               size of a B-Tree cell to store as embedded content on a
   499    568               page that is part of an index B-Tree. Refer to section 
   500    569               <cite>index_btree_cell_format</cite> for details.
   501    570   
   502         -        <tr><td>22     <td>1<td>
          571  +        [Tr]<td>22     <td>1<td>
   503    572               Minimum fraction of an index B-Tree page to use for
   504    573               embedded content when an entry uses one or more overflow pages.
   505    574               This value is used to determine the portion of a B-Tree cell 
   506    575               that requires one or more overflow pages to store as embedded
   507    576               content on a page that is part of an index B-Tree. Refer to
   508    577               section <cite>index_btree_cell_format</cite> for details.
   509    578   
   510         -        <tr><td>23     <td>1<td>
          579  +        [Tr]<td>23     <td>1<td>
   511    580               Minimum fraction of an table B-Tree leaf page to use for
   512    581               embedded content when an entry uses one or more overflow pages.
   513    582               This value is used to determine the portion of a B-Tree cell 
   514    583               that requires one or more overflow pages to store as embedded
   515    584               content on a page that is a leaf of a table B-Tree. Refer to
   516    585               section <cite>table_btree_cell_format</cite> for details.
   517    586   
   518         -        <tr><td>24..27 <td>4<td>
          587  +        [Tr]<td>24..27 <td>4<td>
   519    588               <p style="margin-top:0">
   520    589               The file change counter. Each time a database transaction is
   521    590               committed, the value of the 32-bit unsigned integer stored in
   522    591               this field is incremented.
   523    592               <p style="margin-bottom:0">
   524    593               SQLite uses this field to test the validity of its internal
   525    594               cache. After unlocking the database file, SQLite may retain
................................................................................
   527    596               is unlocked, another process may use SQLite to modify the 
   528    597               contents of the file, invalidating the internal cache of the
   529    598               first process. When the file is relocked, the first process can
   530    599               check if the value of the file change counter has been modified
   531    600               since the file was unlocked. If it has not, then the internal
   532    601               cache may be assumed to be valid and may be reused.
   533    602   
   534         -        <tr><td>32..35 <td>4<td>
          603  +        [Tr]<td>32..35 <td>4<td>
   535    604               Page number of first freelist trunk page. 
   536    605               For more details, refer to section <cite>free_page_list</cite>.
   537    606   
   538         -        <tr><td>36..39 <td>4<td>
          607  +        [Tr]<td>36..39 <td>4<td>
   539    608               Number of free pages in the database file.
   540    609               For more details, refer to section <cite>free_page_list</cite>.
   541    610   
   542         -        <tr><td>40..43 <td>4<td>
          611  +        [Tr]<td>40..43 <td>4<td>
   543    612               The schema version. Each time the database schema is modified (by
   544    613               creating or deleting a database table, index, trigger or view)
   545    614               the value of the 32-bit unsigned integer stored in this field
   546    615               is incremented.
   547    616   
   548         -        <tr><td>44..47 <td>4<td>
          617  +        [Tr]<td>44..47 <td>4<td>
   549    618               <p style="margin-top:0">
   550    619   	    Schema layer file-format. This value is similar to the
   551    620               "read-version" and "write-version" fields at offsets 18 and 19
   552    621               of the database file header. If SQLite encounters a database
   553    622               with a schema layer file-format value greater than the file-format
   554    623               that it understands (currently 4), then SQLite will refuse to
   555    624               access the database.
................................................................................
   565    634   	      <li> Descending indexes (see section
   566    635                      <cite>index_btree_compare_func</cite>) and Boolean values
   567    636   		   in database records (see section <cite>record_format</cite>,
   568    637                      serial types 8 and 9).
   569    638               </ol>
   570    639               
   571    640   
   572         -        <tr><td>48..51 <td>4<td>
          641  +        [Tr]<td>48..51 <td>4<td>
   573    642               Default pager cache size. This field is used by SQLite to store
   574    643               the recommended pager cache size to use for the database.
   575    644   
   576         -        <tr><td>52..55 <td>4<td>
          645  +        [Tr]<td>52..55 <td>4<td>
   577    646               For auto-vacuum capable databases, the numerically largest 
   578    647               root-page number in the database. Since page 1 is always the
   579    648   	    root-page of the schema table (section <cite>schema_table</cite>),
   580    649               this value is always non-zero for auto-vacuum databases. For
   581    650               non-auto-vacuum databases, this value is always zero.
   582    651   
   583         -        <tr><td>56..59 <td>4<td>
          652  +        [Tr]<td>56..59 <td>4<td>
   584    653               (constant) Database text encoding. A value of 1 means all 
   585    654               text values are stored using UTF-8 encoding. 2 indicates
   586    655               little-endian UTF-16 text. A value of 3 means that the database
   587    656               contains big-endian UTF-16 text.  
   588    657   
   589         -        <tr><td>60..63 <td>4<td>
          658  +        [Tr]<td>60..63 <td>4<td>
   590    659               The user-cookie value. A 32-bit integer value available to the
   591    660               user for read/write access.
   592    661   
   593         -        <tr><td>64..67 <td>4<td>
          662  +        [Tr]<td>64..67 <td>4<td>
   594    663               The incremental-vacuum flag. In non-auto-vacuum databases this
   595    664               value is always zero. In auto-vacuum databases, this field is
   596    665               set to 1 if "incremental vacuum" mode is enabled. If incremental
   597    666               vacuum mode is not enabled, then the database file is reorganized
   598    667               so that it contains no free pages (section
   599    668               <cite>free_page_list</cite>) at the end of each database
   600    669               transaction. If incremental vacuum mode is enabled, then the
   601    670               reorganization is not performed until explicitly requested
   602    671               by the user.
   603    672   
   604    673         </table>
          674  +
   605    675         <p>
   606    676           The four byte block beginning at offset 28 is unused. As is the
   607    677           32 byte block beginning at offset 68.
   608    678         </p>
   609    679   
   610    680         <p>
   611    681   	Some of the following requirements state that certain database header
................................................................................
   612    682           fields must contain defined constant values, even though the sqlite 
   613    683           database file format is designed to allow various values. This is
   614    684           done to artificially constrain the definition of a 
   615    685           <i>well-formed database</i> in order to make implementation and 
   616    686           testing more practical.
   617    687   
   618    688         <p class=req id=H30030>
   619         -          <tcl>fileformat_import_requirement H30030</tcl>
          689  +          [fileformat_import_requirement H30030]
   620    690   
   621    691         <p>
   622    692           Following the 16 byte magic string in the file header is the
   623    693   	<i>page size</i>, a 2-byte field. See section
   624    694           <cite>pages_and_page_types</cite> for details.
   625    695   
   626    696         <p class=req id=H30040>
   627         -          <tcl>fileformat_import_requirement H30040</tcl>
          697  +          [fileformat_import_requirement H30040]
   628    698         <p class=req id=H30050>
   629         -          <tcl>fileformat_import_requirement H30050</tcl>
          699  +          [fileformat_import_requirement H30050]
   630    700   
   631    701         <p class=req id=H30060>
   632         -          <tcl>fileformat_import_requirement H30060</tcl>
          702  +          [fileformat_import_requirement H30060]
   633    703   
   634    704         <p class=req id=H30070>
   635         -          <tcl>fileformat_import_requirement H30070</tcl>
          705  +          [fileformat_import_requirement H30070]
   636    706         <p class=req id=H30080>
   637         -          <tcl>fileformat_import_requirement H30080</tcl>
          707  +          [fileformat_import_requirement H30080]
   638    708         <p class=req id=H30090>
   639         -          <tcl>fileformat_import_requirement H30090</tcl>
          709  +          [fileformat_import_requirement H30090]
   640    710         <p class=req id=H30100>
   641         -          <tcl>fileformat_import_requirement H30100</tcl>
          711  +          [fileformat_import_requirement H30100]
   642    712   
   643    713         <p>
   644    714           Following the <i>file change counter</i> in the database header are
   645    715           two 4-byte fields related to the database file <i>free page list</i>.
   646    716           See section <cite>free_page_list</cite> for details.
   647    717   
   648    718         <p class=req id=H30110>
   649         -          <tcl>fileformat_import_requirement H30110</tcl>
          719  +          [fileformat_import_requirement H30110]
   650    720   
   651    721         <p class=req id=H30120>
   652         -          <tcl>fileformat_import_requirement H30120</tcl>
          722  +          [fileformat_import_requirement H30120]
   653    723   
   654    724         <p class=req id=H30130>
   655         -          <tcl>fileformat_import_requirement H30130</tcl>
          725  +          [fileformat_import_requirement H30130]
   656    726   
   657    727         <p class=req id=H30140>
   658         -          <tcl>fileformat_import_requirement H30140</tcl>
          728  +          [fileformat_import_requirement H30140]
   659    729   
   660    730         <p class=req id=H30150>
   661         -          <tcl>fileformat_import_requirement H30150</tcl>
          731  +          [fileformat_import_requirement H30150]
   662    732   
   663    733         <p class=req id=H30160>
   664         -          <tcl>fileformat_import_requirement H30160</tcl>
          734  +          [fileformat_import_requirement H30160]
   665    735   
   666    736         <p class=req id=H30170>
   667         -          <tcl>fileformat_import_requirement H30170</tcl>
          737  +          [fileformat_import_requirement H30170]
   668    738   
   669    739         <p class=req id=H30180>
   670         -          <tcl>fileformat_import_requirement H30180</tcl>
          740  +          [fileformat_import_requirement H30180]
   671    741   
   672         -    <h3 id="pages_and_page_types">Pages and Page Types</h3>
          742  +    [h3 "Pages and Page Types" "pages_and_page_types"]
   673    743         <p>
   674    744           The entire database file is divided into pages, each page consisting
   675    745           of <i>page-size</i> bytes, where <i>page-size</i> is the 2-byte 
   676    746           integer value stored at offset 16 of the file header (see above).
   677    747           The <i>page-size</i> is always a power of two between 512 
   678    748           (2<sup>9</sup>) and 32768 (2<sup>15</sup>). SQLite database files
   679    749           always consist of an exact number of pages.
................................................................................
   698    768               <cite>pointer_map_pages</cite> for details.
   699    769           <li><b>The locking page</b>. The database page that starts at
   700    770               byte offset 2<sup>30</sup>, if it is large enough to contain
   701    771               such a page, is always left unused.
   702    772         </ul>
   703    773   
   704    774         <p class=req id=H30190>
   705         -          <tcl>fileformat_import_requirement H30190</tcl>
          775  +          [fileformat_import_requirement H30190]
   706    776         <p class=req id=H30200>
   707         -          <tcl>fileformat_import_requirement H30200</tcl>
          777  +          [fileformat_import_requirement H30200]
   708    778         <p class=req id=H30210>
   709         -          <tcl>fileformat_import_requirement H30210</tcl>
          779  +          [fileformat_import_requirement H30210]
   710    780         <p class=req id=H30220>
   711         -          <tcl>fileformat_import_requirement H30220</tcl>
          781  +          [fileformat_import_requirement H30220]
   712    782           
   713    783   
   714         -    <h3 id=schema_table>The Schema Table</h3>
          784  +    [h3 "The Schema Table" schema_table]
   715    785         <p>
   716    786           Apart from being the page that contains the file-header, page 1 of
   717    787           the database file is special because it is the root page of the
   718    788           B-Tree structure that contains the schema table data. From the SQL
   719    789           level, the schema table is accessible via the name "sqlite_master".
   720    790         <p>
   721    791           The exact format of the B-Tree structure and the meaning of the term
................................................................................
   730    800   	The schema table contains a record for each SQL table (including
   731    801   	virtual tables) except for sqlite_master, and for each index, trigger
   732    802   	and view in the logical database.  There is also an entry for each
   733    803   	UNIQUE or PRIMARY KEY clause present in the definition of a database
   734    804   	table. Each record in the schema table contains exactly 5 values, in
   735    805           the following order:
   736    806   
   737         -      <table class=striped>
   738         -        <tr><th>Field<th>Description
   739         -        <tr><td>Schema item type.
          807  +      [Table]
          808  +        [Tr]<th>Field<th>Description
          809  +        [Tr]<td>Schema item type.
   740    810   	    <td>A string value. One of "table", "index", "trigger" or "view",
   741    811   		according to the schema item type. Entries associated with
   742    812   		UNIQUE or PRIMARY KEY clauses have this field set to "index".
   743         -        <tr><td>Schema item name.
          813  +        [Tr]<td>Schema item name.
   744    814   	    <td>A string value. The name of the database schema item (table,
   745    815   		index, trigger or view) associated with this record, if any.
   746    816   		Entries associated with UNIQUE or PRIMARY KEY clauses have
   747    817   		this field set to a string of the form
   748    818   		"sqlite_autoindex_&lt;name&gt;_&lt;idx&gt;" where &lt;name&gt;
   749    819   		is the name of the SQL table and &lt;idx&gt; is an integer
   750    820   		value.
   751    821   
   752         -        <tr><td style="white-space:nowrap">Associated table name.
          822  +        [Tr]<td style="white-space:nowrap">Associated table name.
   753    823               <td>A string value. For "table" 
   754    824               or "view" records this is a copy of the second (previous) value. 
   755    825               For "index" and "trigger" records, this field is set to the name 
   756    826               of the associated database table.
   757         -        <tr><td style="white-space:nowrap">The "root page" number. 
          827  +        [Tr]<td style="white-space:nowrap">The "root page" number. 
   758    828   	    <td>For "trigger" and "view" records, as well as "table" records
   759    829   		associated with virtual tables, this is set to NULL. For other
   760    830   		"table" and "index" records (including those associated with
   761    831   		UNIQUE or PRIMARY KEY clauses), this field contains the root
   762    832   		page number (an integer) of the B-Tree structure that contains
   763    833   		the table or index data.
   764         -        <tr><td>The SQL statement.
          834  +        [Tr]<td>The SQL statement.
   765    835               <td>A string value. The SQL statement used to create the schema
   766    836                   item (i.e.  the complete text of an SQL "CREATE TABLE"
   767    837   		statement). This field contains an empty string for table
   768    838   		entries associated with PRIMARY KEY or UNIQUE clauses.
   769    839   		<span class=todo>Refer to some document that describes these
   770    840   	        SQL statements more precisely.</span>
   771    841         </table>
................................................................................
   803    873             CREATE INDEX i1 ON abc(b, c);
   804    874             CREATE TABLE main.def(a PRIMARY KEY, b, c, UNIQUE(b, c));
   805    875             CREATE VIEW v1 AS SELECT * FROM abc;
   806    876         </pre>
   807    877         <p>
   808    878           Then the schema table would contain a total of 7 records, as follows:
   809    879   
   810         -      <table class=striped>
   811         -        <tr><th>Field 1<th>Field 2<th>Field 3<th>Field 4<th>Field 5
   812         -        <tr><td>table <td>abc <td>abc <td>2 <td>CREATE TABLE abc(a, b, c)
   813         -        <tr><td>index <td>i1 <td>abc <td>3 <td>CREATE INDEX i1 ON abc(b, c)
   814         -        <tr><td>table <td>def <td>def <td>4 <td>CREATE TABLE def(a PRIMARY KEY, b, c, UNIQUE(b, c))
   815         -        <tr><td>index <td>sqlite_autoindex_def_1 <td>def <td>5 <td>
   816         -        <tr><td>index <td>sqlite_autoindex_def_2 <td>def <td>6 <td>
   817         -        <tr><td>view <td>v1 <td>v1 <td>0 <td>CREATE VIEW v1 AS SELECT * FROM abc
          880  +      [Table]
          881  +        [Tr]<th>Field 1<th>Field 2<th>Field 3<th>Field 4<th>Field 5
          882  +        [Tr]<td>table <td>abc <td>abc <td>2 <td>CREATE TABLE abc(a, b, c)
          883  +        [Tr]<td>index <td>i1 <td>abc <td>3 <td>CREATE INDEX i1 ON abc(b, c)
          884  +        [Tr]<td>table <td>def <td>def <td>4 <td>CREATE TABLE def(a PRIMARY KEY, b, c, UNIQUE(b, c))
          885  +        [Tr]<td>index <td>sqlite_autoindex_def_1 <td>def <td>5 <td>
          886  +        [Tr]<td>index <td>sqlite_autoindex_def_2 <td>def <td>6 <td>
          887  +        [Tr]<td>view <td>v1 <td>v1 <td>0 <td>CREATE VIEW v1 AS SELECT * FROM abc
   818    888         </table>
   819    889   
   820    890         <p class=req id=H30230>
   821         -          <tcl>fileformat_import_requirement H30230</tcl>
          891  +          [fileformat_import_requirement H30230]
   822    892         <p class=req id=H30240>
   823         -          <tcl>fileformat_import_requirement H30240</tcl>
          893  +          [fileformat_import_requirement H30240]
   824    894   
   825    895         <p>The following requirements describe "table" records.
   826    896   
   827    897         <p class=req id=H30250>
   828         -          <tcl>fileformat_import_requirement H30250</tcl>
          898  +          [fileformat_import_requirement H30250]
   829    899   
   830    900         <p class=req id=H30260>
   831         -          <tcl>fileformat_import_requirement H30260</tcl>
          901  +          [fileformat_import_requirement H30260]
   832    902   
   833    903         <p class=req id=H30270>
   834         -          <tcl>fileformat_import_requirement H30270</tcl>
          904  +          [fileformat_import_requirement H30270]
   835    905   
   836    906         <p class=req id=H30280>
   837         -          <tcl>fileformat_import_requirement H30280</tcl>
          907  +          [fileformat_import_requirement H30280]
   838    908   
   839    909         <p class=req id=H30290>
   840         -          <tcl>fileformat_import_requirement H30290</tcl>
          910  +          [fileformat_import_requirement H30290]
   841    911   
   842    912         <p class=req id=H30300>
   843         -          <tcl>fileformat_import_requirement H30300</tcl>
          913  +          [fileformat_import_requirement H30300]
   844    914   
   845    915         <p class=req id=H30310>
   846         -          <tcl>fileformat_import_requirement H30310</tcl>
          916  +          [fileformat_import_requirement H30310]
   847    917   
   848    918         <p>The following requirements describe "implicit index" records.
   849    919   
   850    920         <p class=req id=H30320>
   851         -          <tcl>fileformat_import_requirement H30320</tcl>
          921  +          [fileformat_import_requirement H30320]
   852    922   
   853    923         <p class=req id=H30330>
   854         -          <tcl>fileformat_import_requirement H30330</tcl>
          924  +          [fileformat_import_requirement H30330]
   855    925         <p class=req id=H30340>
   856         -          <tcl>fileformat_import_requirement H30340</tcl>
          926  +          [fileformat_import_requirement H30340]
   857    927         <p class=req id=H30350>
   858         -          <tcl>fileformat_import_requirement H30350</tcl>
          928  +          [fileformat_import_requirement H30350]
   859    929   
   860    930         <p>The following requirements describe "explicit index" records.
   861    931   
   862    932         <p class=req id=H30360>
   863         -          <tcl>fileformat_import_requirement H30360</tcl>
          933  +          [fileformat_import_requirement H30360]
   864    934         <p class=req id=H30370>
   865         -          <tcl>fileformat_import_requirement H30370</tcl>
          935  +          [fileformat_import_requirement H30370]
   866    936         <p class=req id=H30380>
   867         -          <tcl>fileformat_import_requirement H30380</tcl>
          937  +          [fileformat_import_requirement H30380]
   868    938         <p class=req id=H30390>
   869         -          <tcl>fileformat_import_requirement H30390</tcl>
          939  +          [fileformat_import_requirement H30390]
   870    940   
   871    941         <p>The following requirements describe "view" records.
   872    942   
   873    943         <p class=req id=H30400>
   874         -          <tcl>fileformat_import_requirement H30400</tcl>
          944  +          [fileformat_import_requirement H30400]
   875    945   
   876    946         <p class=req id=H30410>
   877         -          <tcl>fileformat_import_requirement H30410</tcl>
          947  +          [fileformat_import_requirement H30410]
   878    948   
   879    949         <p class=req id=H30420>
   880         -          <tcl>fileformat_import_requirement H30420</tcl>
          950  +          [fileformat_import_requirement H30420]
   881    951   
   882    952         <p class=req id=H30430>
   883         -          <tcl>fileformat_import_requirement H30430</tcl>
          953  +          [fileformat_import_requirement H30430]
   884    954   
   885    955         <p>The following requirements describe "trigger" records.
   886    956   
   887    957         <p class=req id=H30440>
   888         -          <tcl>fileformat_import_requirement H30440</tcl>
          958  +          [fileformat_import_requirement H30440]
   889    959   
   890    960         <p class=req id=H30450>
   891         -          <tcl>fileformat_import_requirement H30450</tcl>
          961  +          [fileformat_import_requirement H30450]
   892    962   
   893    963         <p class=req id=H30460>
   894         -          <tcl>fileformat_import_requirement H30460</tcl>
          964  +          [fileformat_import_requirement H30460]
   895    965   
   896    966         <p class=req id=H30470>
   897         -          <tcl>fileformat_import_requirement H30470</tcl>
          967  +          [fileformat_import_requirement H30470]
   898    968   
   899    969         <p>The following requirements describe the placement of B-Tree root 
   900    970            pages in auto-vacuum databases.
   901    971   
   902    972         <p class=req id=H30480>
   903         -          <tcl>fileformat_import_requirement H30480</tcl>
          973  +          [fileformat_import_requirement H30480]
   904    974   
   905    975         <p class=req id=H30490>
   906         -          <tcl>fileformat_import_requirement H30490</tcl>
          976  +          [fileformat_import_requirement H30490]
   907    977   
   908    978   
   909    979    
   910         -  <h2 id="btree_structures">B-Tree Structures</h2>
          980  +  [h2 "B-Tree Structures" "btree_structures"]
   911    981       <p>
   912    982         A large part of any SQLite database file is given over to one or more
   913    983         B-Tree structures. A single B-Tree structure is stored using one or more
   914    984         database pages. Each page contains a single B-Tree node.
   915    985         The pages used to store a single B-Tree structure need not form a
   916    986         contiguous block. The page that contains the root node of a B-Tree
   917    987         structure is known as the "root page".
................................................................................
   926    996             <cite>table_btrees</cite>.
   927    997         <li>The <b>index B-Tree</b>, which uses database records as keys. Index
   928    998             B-Tree structures are described in detail in section 
   929    999             <cite>index_btrees</cite>.
   930   1000       </ul>
   931   1001   
   932   1002       <p class=req id=H30500>
   933         -          <tcl>fileformat_import_requirement H30500</tcl>
         1003  +          [fileformat_import_requirement H30500]
   934   1004       <p class=req id=H30510>
   935         -          <tcl>fileformat_import_requirement H30510</tcl>
         1005  +          [fileformat_import_requirement H30510]
   936   1006   
   937         -    <h3 id="varint_format">Variable Length Integer Format</h3>
         1007  +    [h3 "Variable Length Integer Format" "varint_format"]
   938   1008         <p>
   939   1009   	In several parts of the B-Tree structure, 64-bit twos-complement signed
   940   1010   	integer values are stored in the "variable length integer format"
   941   1011   	described here.
   942   1012         <p>
   943   1013           A variable length integer consumes from one to nine bytes of space,
   944   1014           depending on the value stored. Seven bits are used from each of
................................................................................
   951   1021   	significant set bit in the 64-bit word. Negative numbers always have
   952   1022   	the most significant bit of the word (the sign bit) set and so are
   953   1023   	always encoded using the full nine bytes. Positive integers may be
   954   1024   	encoded using less space. The following table shows the 9 different
   955   1025   	length formats available for storing a variable length integer
   956   1026   	value.
   957   1027   
   958         -      <table class=striped>
   959         -        <tr><th>Bytes<th>Value Range<th>Bit Pattern
   960         -        <tr><td>1<td>7 bit<td>0xxxxxxx
   961         -        <tr><td>2<td>14 bit<td>1xxxxxxx 0xxxxxxx
   962         -        <tr><td>3<td>21 bit<td>1xxxxxxx 1xxxxxxx 0xxxxxxx
   963         -        <tr><td>4<td>28 bit<td>1xxxxxxx 1xxxxxxx 1xxxxxxx 0xxxxxxx
   964         -        <tr><td>5<td>35 bit<td>1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 0xxxxxxx
   965         -        <tr><td>6<td>42 bit<td>1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 0xxxxxxx
   966         -        <tr><td>7<td>49 bit<td>1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 0xxxxxxx
   967         -        <tr><td>8<td>56 bit<td>1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 0xxxxxxx
   968         -        <tr><td>9<td>64 bit<td>1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx xxxxxxxx
         1028  +      [Table]
         1029  +        [Tr]<th>Bytes<th>Value Range<th>Bit Pattern
         1030  +        [Tr]<td>1<td>7 bit<td>0xxxxxxx
         1031  +        [Tr]<td>2<td>14 bit<td>1xxxxxxx 0xxxxxxx
         1032  +        [Tr]<td>3<td>21 bit<td>1xxxxxxx 1xxxxxxx 0xxxxxxx
         1033  +        [Tr]<td>4<td>28 bit<td>1xxxxxxx 1xxxxxxx 1xxxxxxx 0xxxxxxx
         1034  +        [Tr]<td>5<td>35 bit<td>1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 0xxxxxxx
         1035  +        [Tr]<td>6<td>42 bit<td>1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 0xxxxxxx
         1036  +        [Tr]<td>7<td>49 bit<td>1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 0xxxxxxx
         1037  +        [Tr]<td>8<td>56 bit<td>1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 0xxxxxxx
         1038  +        [Tr]<td>9<td>64 bit<td>1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx xxxxxxxx
   969   1039         </table>
   970   1040         <p>
   971   1041           When using the full 9 byte representation, the first byte contains
   972   1042           the 7 most significant bits of the 64-bit value. The final byte of
   973   1043           the 9 byte representation contains the 8 least significant bits of
   974   1044           the 64-bit value. When using one of the other representations, the
   975   1045           final byte contains the 7 least significant bits of the 64-bit value.
................................................................................
   979   1049         <p>
   980   1050   	When encoding a variable length integer, SQLite usually selects the
   981   1051           most compact representation that provides enough storage to accomadate
   982   1052   	the most significant set bit of the value. This is not required
   983   1053           however, using more bytes than is strictly necessary when encoding
   984   1054           an integer is valid.
   985   1055   
   986         -      <table class=striped>
   987         -	<tr><th>Decimal<th>Hexadecimal        <th>Variable Length Integer
   988         -	<tr><td>43     <td>0x000000000000002B <td>0x2B
   989         -	<tr><td>200815 <td>0x000000000003106F <td>0x8C 0xA0 0x6F
   990         -        <tr><td>-1     <td>0xFFFFFFFFFFFFFFFF 
         1056  +      [Table]
         1057  +	[Tr]<th>Decimal<th>Hexadecimal        <th>Variable Length Integer
         1058  +	[Tr]<td>43     <td>0x000000000000002B <td>0x2B
         1059  +	[Tr]<td>200815 <td>0x000000000003106F <td>0x8C 0xA0 0x6F
         1060  +        [Tr]<td>-1     <td>0xFFFFFFFFFFFFFFFF 
   991   1061               <td>0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
   992         -        <tr><td>-78056 <td>0xFFFFFFFFFFFECD56
         1062  +        [Tr]<td>-78056 <td>0xFFFFFFFFFFFECD56
   993   1063               <td>0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFD 0xCD 0x56
   994   1064         </table>
   995   1065   
   996   1066       <p class=req id=H30520>
   997         -          <tcl>fileformat_import_requirement H30520</tcl>
         1067  +          [fileformat_import_requirement H30520]
   998   1068   
   999   1069       <p class=req id=H30530>
  1000         -          <tcl>fileformat_import_requirement H30530</tcl>
         1070  +          [fileformat_import_requirement H30530]
  1001   1071   
  1002   1072       <p class=req id=H30540>
  1003         -          <tcl>fileformat_import_requirement H30540</tcl>
         1073  +          [fileformat_import_requirement H30540]
  1004   1074   
  1005   1075       <p class=req id=H30550>
  1006         -          <tcl>fileformat_import_requirement H30550</tcl>
         1076  +          [fileformat_import_requirement H30550]
  1007   1077         
  1008   1078   
  1009         -    <h3 id="record_format">Database Record Format</h3>
         1079  +    [h3 "Database Record Format" "record_format"]
  1010   1080         <p>
  1011   1081           A database record is a blob of data that represents an ordered
  1012   1082           list of one or more SQL values. Database records are used in two
  1013   1083           places in SQLite database files - as the associated data for entries
  1014   1084           in table B-Tree structures, and as the key values in index B-Tree
  1015   1085           structures. The size (number of bytes consumed by) a database record
  1016   1086           depends on the values it contains.
................................................................................
  1022   1092         <p>
  1023   1093           The first variable length integer in a record header contains the
  1024   1094           size of the record header in bytes. The following <i>N</i> variable
  1025   1095           length integer values each describe the type and size of the 
  1026   1096           records corresponding SQL value (the second integer in the record
  1027   1097           header describes the first value in the record, etc.). Integer
  1028   1098           values are interpreted according to the following table:
  1029         -      <table class=striped>
  1030         -        <tr><th>Header Value <th>Data type and size
  1031         -        <tr><td>0 
         1099  +      [Table]
         1100  +        [Tr]<th>Header Value <th>Data type and size
         1101  +        [Tr]<td>0 
  1032   1102               <td>An SQL NULL value (type SQLITE_NULL). This value
  1033   1103                   consumes zero bytes of space in the record's data area.
  1034         -        <tr><td>1
         1104  +        [Tr]<td>1
  1035   1105               <td>An SQL integer value (type SQLITE_INTEGER), stored as a
  1036   1106                   big-endian 1-byte signed integer.
  1037         -        <tr><td>2
         1107  +        [Tr]<td>2
  1038   1108               <td>An SQL integer value (type SQLITE_INTEGER), stored as a
  1039   1109                   big-endian 2-byte signed integer.
  1040         -        <tr><td>3
         1110  +        [Tr]<td>3
  1041   1111               <td>An SQL integer value (type SQLITE_INTEGER), stored as a
  1042   1112                   big-endian 3-byte signed integer.
  1043         -        <tr><td>4
         1113  +        [Tr]<td>4
  1044   1114               <td>An SQL integer value (type SQLITE_INTEGER), stored as a
  1045   1115                   big-endian 4-byte signed integer.
  1046         -        <tr><td>5
         1116  +        [Tr]<td>5
  1047   1117               <td>An SQL integer value (type SQLITE_INTEGER), stored as a
  1048   1118                   big-endian 6-byte signed integer.
  1049         -        <tr><td>6
         1119  +        [Tr]<td>6
  1050   1120               <td>An SQL integer value (type SQLITE_INTEGER), stored as an
  1051   1121                   big-endian 8-byte signed integer.
  1052         -        <tr><td>7
         1122  +        [Tr]<td>7
  1053   1123               <td>An SQL real value (type SQLITE_FLOAT), stored as an
  1054   1124                   8-byte IEEE floating point value.
  1055         -        <tr><td>8
         1125  +        [Tr]<td>8
  1056   1126               <td>The literal SQL integer 0 (type SQLITE_INTEGER). The value 
  1057   1127                   consumes zero bytes of space in the record's data area.
  1058   1128                   Values of this type are only present in databases with
  1059   1129                   a schema file format (the 32-bit integer at byte offset 44
  1060   1130                   of the database file header) value of 4 or greater.
  1061   1131   
  1062         -        <tr><td>9
         1132  +        [Tr]<td>9
  1063   1133               <td>The literal SQL integer 1 (type SQLITE_INTEGER). The value
  1064   1134                   consumes zero bytes of space in the record's data area.
  1065   1135                   Values of this type are only present in databases with
  1066   1136                   a schema file format (the 32-bit integer at byte offset 44
  1067   1137                   of the database file header) value of 4 or greater.
  1068   1138   
  1069         -        <tr><td style="white-space:nowrap"><i>bytes</i> * 2 + 12
         1139  +        [Tr]<td style="white-space:nowrap"><i>bytes</i> * 2 + 12
  1070   1140               <td>Even values greater than 12 are used to signify a blob of
  1071   1141                   data (type SQLITE_BLOB) (<i>n</i>-12)/2 bytes in length, where
  1072   1142                   <i>n</i> is the integer value stored in the record header.
  1073   1143                   
  1074         -        <tr><td style="white-space:nowrap"><i>bytes</i> * 2 + 13
         1144  +        [Tr]<td style="white-space:nowrap"><i>bytes</i> * 2 + 13
  1075   1145               <td>Odd values greater than 12 are used to signify a string
  1076   1146                   (type SQLITE_TEXT) (<i>n</i>-13)/2 bytes in length, where
  1077   1147                   <i>n</i> is the integer value stored in the record header.
  1078   1148         </table>
  1079   1149         <p>
  1080   1150           Immediately following the record header is the data for each
  1081   1151           of the record's values. A record containing <i>N</i> values is
  1082   1152           depicted in figure <cite>figure_recordformat</cite>.
  1083         -      <center><img src="images/fileformat/recordformat.gif">
  1084         -      <p><i>Figure <span class=fig id=figure_recordformat></span> - Database Record Format.</i>
  1085         -      </center>
         1153  +
         1154  +        [Figure recordformat.gif figure_recordformat "Database Record Format"]
  1086   1155         
  1087   1156         <p>
  1088   1157           For each SQL value in the record, there is a blob of data stored
  1089   1158           in the records data area. If the corresponding integer type value
  1090   1159           in the record header is 0 (NULL), 8 (integer value 0) or 9 (integer
  1091   1160           value 1), then the blob of data is zero bytes in length. Otherwise,
  1092   1161           the length of the data field is as described in the table above.
................................................................................
  1093   1162         <p>
  1094   1163           The data field associated with a string value contains the string
  1095   1164           encoded using the database encoding, as defined in the database
  1096   1165           file header (see section <cite>file_header</cite>). No 
  1097   1166           nul-terminator character is stored in the database.
  1098   1167   
  1099   1168         <p class=req id=H30560>
  1100         -          <tcl>fileformat_import_requirement H30560</tcl>
         1169  +          [fileformat_import_requirement H30560]
  1101   1170   
  1102   1171         <p class=req id=H30570>
  1103         -          <tcl>fileformat_import_requirement H30570</tcl>
         1172  +          [fileformat_import_requirement H30570]
  1104   1173   
  1105   1174         <p class=req id=H30580>
  1106         -          <tcl>fileformat_import_requirement H30580</tcl>
         1175  +          [fileformat_import_requirement H30580]
  1107   1176   
  1108   1177         <p class=req id=H30590>
  1109         -          <tcl>fileformat_import_requirement H30590</tcl>
         1178  +          [fileformat_import_requirement H30590]
  1110   1179   
  1111   1180         <p class=req id=H30600>
  1112         -          <tcl>fileformat_import_requirement H30600</tcl>
         1181  +          [fileformat_import_requirement H30600]
  1113   1182         <p class=req id=H30610>
  1114         -          <tcl>fileformat_import_requirement H30610</tcl>
         1183  +          [fileformat_import_requirement H30610]
  1115   1184         <p class=req id=H30620>
  1116         -          <tcl>fileformat_import_requirement H30620</tcl>
         1185  +          [fileformat_import_requirement H30620]
  1117   1186         <p class=req id=H30630>
  1118         -          <tcl>fileformat_import_requirement H30630</tcl>
         1187  +          [fileformat_import_requirement H30630]
  1119   1188         <p class=req id=H30640>
  1120         -          <tcl>fileformat_import_requirement H30640</tcl>
         1189  +          [fileformat_import_requirement H30640]
  1121   1190         <p class=req id=H30650>
  1122         -          <tcl>fileformat_import_requirement H30650</tcl>
         1191  +          [fileformat_import_requirement H30650]
  1123   1192   
  1124   1193         <p class=req id=H30660>
  1125         -          <tcl>fileformat_import_requirement H30660</tcl>
         1194  +          [fileformat_import_requirement H30660]
  1126   1195   
  1127   1196         <p class=req id=H30670>
  1128         -          <tcl>fileformat_import_requirement H30670</tcl>
         1197  +          [fileformat_import_requirement H30670]
  1129   1198   
  1130   1199         <p class=req id=H30680>
  1131         -          <tcl>fileformat_import_requirement H30680</tcl>
         1200  +          [fileformat_import_requirement H30680]
  1132   1201   
  1133   1202         <p class=req id=H30690>
  1134         -          <tcl>fileformat_import_requirement H30690</tcl>
         1203  +          [fileformat_import_requirement H30690]
  1135   1204   
  1136   1205         <p class=req id=H30700>
  1137         -          <tcl>fileformat_import_requirement H30700</tcl>
         1206  +          [fileformat_import_requirement H30700]
  1138   1207   
  1139   1208         <p>
  1140   1209           The following database file properties define restrictions on the 
  1141   1210           integer values that may be stored within a 
  1142   1211           <i>database record header</i>.
  1143   1212   
  1144   1213         <p class=req id=H30710>
  1145         -          <tcl>fileformat_import_requirement H30710</tcl>
         1214  +          [fileformat_import_requirement H30710]
  1146   1215         <p class=req id=H30720>
  1147         -          <tcl>fileformat_import_requirement H30720</tcl>
         1216  +          [fileformat_import_requirement H30720]
  1148   1217   
  1149         -    <h3 id=index_btrees>Index B-Trees</h3>
         1218  +    [h3 "Index B-Trees" index_btrees]
  1150   1219         <p>
  1151   1220           As specified in section <cite>fileformat_overview</cite>, index 
  1152   1221           B-Tree structures store a unique set of the database records described
  1153   1222           in the previous section. While in some cases, when there are very
  1154   1223           few entries in the B-Tree, the entire structure may fit on a single
  1155   1224           database page, usually the database records must be spread across
  1156   1225           two or more pages. In this case, the pages are organized into a
................................................................................
  1175   1244           the first record stored on the internal node ( R(0) ) by the 
  1176   1245           comparison function described in section
  1177   1246           <cite>index_btree_compare_func</cite>. Similarly all records stored 
  1178   1247           in the sub-tree headed by C(n) are considered greater than R(n-1) but
  1179   1248           less than R(n) for values of n between 1 and N-2, inclusive. All
  1180   1249           records in the sub-tree headed by C(N-1) are greater than the 
  1181   1250           largest record stored on the internal node.
  1182         -        <center><img src="images/fileformat/indextree.gif">
  1183         -        <p><i>Figure <span class=fig id=figure_indextree></span> - Index B-Tree Tree Structure.</i>
  1184         -        </center>
         1251  +
         1252  +        [Figure indextree.gif figure_indextree "Index B-Tree Tree Structure"]
         1253  +
  1185   1254         <p>
  1186   1255           Figure <cite>figure_indextree</cite> depicts one possible record
  1187   1256           distribution for an index B-Tree containing records R1 to R26, assuming
  1188   1257           that for all values of N, <i>R(N+1)&gt;R(N)</i>. In total the B-Tree
  1189   1258           structure uses 11 database file pages. Internal tree nodes contain
  1190   1259           database records and references to child node pages. Leaf nodes contain
  1191   1260           database records only.
  1192   1261   
  1193   1262         <p class=req id=H30730>
  1194         -          <tcl>fileformat_import_requirement H30730</tcl>
         1263  +          [fileformat_import_requirement H30730]
  1195   1264   
  1196   1265         <p class=req id=H30740>
  1197         -          <tcl>fileformat_import_requirement H30740</tcl>
         1266  +          [fileformat_import_requirement H30740]
  1198   1267   
  1199   1268         <p class=req id=H30750>
  1200         -          <tcl>fileformat_import_requirement H30750</tcl>
         1269  +          [fileformat_import_requirement H30750]
  1201   1270   
  1202   1271         <p class=req id=H30760>
  1203         -          <tcl>fileformat_import_requirement H30760</tcl>
         1272  +          [fileformat_import_requirement H30760]
  1204   1273   
  1205   1274         <p>
  1206   1275   	The precise way in which index B-Tree pages and cells are formatted is
  1207   1276           described in subsequent sections.
  1208   1277   
  1209   1278   
  1210         -        <h4>Index B-Tree Content</h4>
         1279  +        [h4 "Index B-Tree Content"]
  1211   1280             <p>
  1212   1281   	    The database file contains one index B-Tree for each database index
  1213   1282   	    in the logical database, including those created by UNIQUE or
  1214   1283   	    PRIMARY KEY clauses in table declarations. Each record stored in
  1215   1284               an index B-Tree contains the same number of fields, the number of
  1216   1285               indexed columns in the database index declaration plus one. 
  1217   1286             <p>
................................................................................
  1218   1287               An index B-Tree contains an entry for each row in its associated
  1219   1288               database table. The fields of the record used as the index B-Tree
  1220   1289               key are copies of each of the indexed columns of the associated 
  1221   1290               database row, in order, followed by the rowid value of the same 
  1222   1291               row. See figure <cite>figure_examplepop</cite> for an example.
  1223   1292   
  1224   1293           <p class=req id=H30770>
  1225         -          <tcl>fileformat_import_requirement H30770</tcl>
         1294  +          [fileformat_import_requirement H30770]
  1226   1295   
  1227   1296           <p class=req id=H30780>
  1228         -          <tcl>fileformat_import_requirement H30780</tcl>
         1297  +          [fileformat_import_requirement H30780]
  1229   1298   
  1230   1299           <p class=req id=H30790>
  1231         -          <tcl>fileformat_import_requirement H30790</tcl>
         1300  +          [fileformat_import_requirement H30790]
  1232   1301   
  1233   1302           <p class=req id=H30800>
  1234         -          <tcl>fileformat_import_requirement H30800</tcl>
         1303  +          [fileformat_import_requirement H30800]
  1235   1304    
  1236         -      <h4 id="index_btree_compare_func">Record Sort Order</h4>
         1305  +      [h4 "Record Sort Order" "index_btree_compare_func"]
  1237   1306           <p>
  1238   1307             This section defines the comparison function used when database
  1239   1308   	  records are used as B-Tree keys for index B-Trees. The comparison
  1240   1309   	  function is only defined when both database records contain the same
  1241   1310             number of fields.
  1242   1311           <p>
  1243   1312             When comparing two database records, the first field of one
................................................................................
  1282   1351             KEY clauses are never treated as descending.
  1283   1352   
  1284   1353           <p class=todo>
  1285   1354             Need requirements style statements for this information. Easier
  1286   1355             to do once collation sequences have been defined somewhere.
  1287   1356   
  1288   1357   
  1289         -      <h4 id=index_btree_page_format>Index B-Tree Page Format</h4>
         1358  +      [h4 "Index B-Tree Page Format" index_btree_page_format]
  1290   1359           <p>
  1291   1360             Each index B-Tree page is divided into four sections that occur
  1292   1361             in order on the page:
  1293   1362           <ul>
  1294   1363             <li> The 8 (leaf node pages) or 12 (internal tree node pages) 
  1295   1364                  byte page-header.
  1296   1365             <li> The cell offset array. This is a series of N big-endian 2-byte
  1297   1366                  integer values, where N is the number of records stored on 
  1298   1367                  the page.
  1299   1368             <li> A block of unused space. This may be 0 bytes in size.
  1300   1369             <li> The cell content area consumes the remaining space on the page.
  1301   1370           </ul>
  1302         -        <center><img src="images/fileformat/indexpage.gif">
  1303         -        <p><i>Figure <span class=fig id=figure_indexpage></span> - Index B-Tree Page Data.</i>
  1304         -        </center>
         1371  +        [Figure indexpage.gif figure_indexpage "Index B-Tree Page Data"]
  1305   1372           <p>
  1306   1373             The 8 (leaf node pages) or 12 (internal tree node pages) byte page
  1307   1374             header that begins each index B-Tree page is made up of a series of 
  1308   1375             1, 2 and 4 byte unsigned integer values as shown in the following
  1309   1376             table. All values are stored in big-endian byte order.
  1310   1377   
  1311         -      <table class=striped>
  1312         -        <tr><th>Byte Range <th>Byte Size <th width=100%>Description
  1313         -        <tr><td>0     <td>1<td>B-Tree page flags. For an index B-Tree internal 
         1378  +      [Table]
         1379  +        [Tr]<th>Byte Range <th>Byte Size <th width=100%>Description
         1380  +        [Tr]<td>0     <td>1<td>B-Tree page flags. For an index B-Tree internal 
  1314   1381                                  tree node page, this is set to 0x02. For a
  1315   1382                                  leaf node page, 0x0A.
  1316         -        <tr><td>1..2  <td>2<td>Byte offset of first block of free space on 
         1383  +        [Tr]<td>1..2  <td>2<td>Byte offset of first block of free space on 
  1317   1384                                  this page. If there are no free blocks on this
  1318   1385                                  page, this field is set to 0.
  1319         -        <tr><td>3..4  <td>2<td>Number of cells (entries) on this page.
  1320         -        <tr><td>5..6  <td>2<td>Byte offset of the first byte of the cell
         1386  +        [Tr]<td>3..4  <td>2<td>Number of cells (entries) on this page.
         1387  +        [Tr]<td>5..6  <td>2<td>Byte offset of the first byte of the cell
  1321   1388                                  content area (see figure 
  1322   1389                                  <cite>figure_indexpage</cite>), relative to the 
  1323   1390                                  start of the page.
  1324         -        <tr><td>7     <td>1<td>Number of fragmented free bytes on page.
  1325         -        <tr><td>8..11 <td>4<td>Page number of rightmost child-page (the
         1391  +        [Tr]<td>7     <td>1<td>Number of fragmented free bytes on page.
         1392  +        [Tr]<td>8..11 <td>4<td>Page number of rightmost child-page (the
  1326   1393                                  child-page that heads the sub-tree in which all
  1327   1394                                  records are larger than all records stored on
  1328   1395                                  this page). This field is not present for leaf
  1329   1396                                  node pages.
  1330   1397         </table>
  1331   1398         <p>
  1332   1399           The cell content area, which occurs last on the page, contains one
................................................................................
  1373   1440               unsigned integer. The first two bytes of the final block in the 
  1374   1441               list are set to zero. The third and fourth bytes of each free
  1375   1442               block contain the total size of the free block in bytes, stored
  1376   1443               as a 2 byte big-endian unsigned integer.
  1377   1444         </ul>
  1378   1445   
  1379   1446         <p class=req id=H30810>
  1380         -          <tcl>fileformat_import_requirement H30810</tcl>
         1447  +          [fileformat_import_requirement H30810]
  1381   1448         <p class=req id=H30820>
  1382         -          <tcl>fileformat_import_requirement H30820</tcl>
         1449  +          [fileformat_import_requirement H30820]
  1383   1450   
  1384   1451         <p>
  1385   1452           The following requirements describe the <i>B-Tree page header</i>
  1386   1453           present at the start of both index and table B-Tree pages.
  1387   1454   
  1388   1455         <p class=req id=H30830>
  1389         -          <tcl>fileformat_import_requirement H30830</tcl>
         1456  +          [fileformat_import_requirement H30830]
  1390   1457   
  1391   1458         <p class=req id=H30840>
  1392         -          <tcl>fileformat_import_requirement H30840</tcl>
         1459  +          [fileformat_import_requirement H30840]
  1393   1460   
  1394   1461         <p class=req id=H30850>
  1395         -          <tcl>fileformat_import_requirement H30850</tcl>
         1462  +          [fileformat_import_requirement H30850]
  1396   1463   
  1397   1464         <p class=req id=H30860>
  1398         -          <tcl>fileformat_import_requirement H30860</tcl>
         1465  +          [fileformat_import_requirement H30860]
  1399   1466   
  1400   1467         <p>
  1401   1468           This requirement describes the cell content offset array. It applies
  1402   1469           to both B-Tree variants.
  1403   1470   
  1404   1471         <p class=req id=H30870>
  1405         -          <tcl>fileformat_import_requirement H30870</tcl>
         1472  +          [fileformat_import_requirement H30870]
  1406   1473   
  1407   1474         <p class=req id=H30880>
  1408         -          <tcl>fileformat_import_requirement H30880</tcl>
         1475  +          [fileformat_import_requirement H30880]
  1409   1476   
  1410   1477         <p class=req id=H30890>
  1411         -          <tcl>fileformat_import_requirement H30890</tcl>
         1478  +          [fileformat_import_requirement H30890]
  1412   1479   
  1413   1480         <p class=req id=H30900>
  1414         -          <tcl>fileformat_import_requirement H30900</tcl>
         1481  +          [fileformat_import_requirement H30900]
  1415   1482   
  1416   1483         <p class=req id=H30910>
  1417         -          <tcl>fileformat_import_requirement H30910</tcl>
         1484  +          [fileformat_import_requirement H30910]
  1418   1485   
  1419   1486         <p>
  1420   1487   	The following requirements govern management of free-space within the
  1421   1488           page content area (both table and index B-Tree pages).
  1422   1489   
  1423   1490         <p class=req id=H30920>
  1424         -          <tcl>fileformat_import_requirement H30920</tcl>
         1491  +          [fileformat_import_requirement H30920]
  1425   1492   
  1426   1493         <p class=req id=H30930>
  1427         -          <tcl>fileformat_import_requirement H30930</tcl>
         1494  +          [fileformat_import_requirement H30930]
  1428   1495   
  1429   1496         <p class=req id=H30940>
  1430         -          <tcl>fileformat_import_requirement H30940</tcl>
         1497  +          [fileformat_import_requirement H30940]
  1431   1498   
  1432   1499         <p class=req id=H30950>
  1433         -          <tcl>fileformat_import_requirement H30950</tcl>
         1500  +          [fileformat_import_requirement H30950]
  1434   1501   
  1435   1502   
  1436   1503         <p class=req id=H30960>
  1437         -          <tcl>fileformat_import_requirement H30960</tcl>
         1504  +          [fileformat_import_requirement H30960]
  1438   1505   
  1439         -      <h4 id=index_btree_cell_format>Index B-Tree Cell Format</h4>
         1506  +      [h4 "Index B-Tree Cell Format" index_btree_cell_format]
  1440   1507           <p> 
  1441   1508             For index B-Tree internal tree node pages, each B-Tree cell begins
  1442   1509             with a child page-number, stored as a 4-byte big-endian unsigned
  1443   1510             integer. This field is omitted for leaf pages, which have no 
  1444   1511             children.
  1445   1512           <p> 
  1446   1513             Following the child page number is the total number of bytes 
................................................................................
  1455   1522   </pre>
  1456   1523           <p>
  1457   1524             bytes. In the formula above, <i>usable-size</i> is the page-size
  1458   1525             in bytes less the number of unused bytes left at the end of every
  1459   1526             page (as read from byte offset 20 of the file header), and
  1460   1527             <i>max-embedded-fraction</i> is the value read from byte offset 
  1461   1528             21 of the file header.
  1462         -        <center><img src="images/fileformat/indexshortrecord.gif">
  1463         -        <p><i>Figure <span class=fig></span> - Small Record Index B-Tree Cell.</i>
  1464         -        </center>
         1529  +        [Figure indexshortrecord.gif figure_indexshortrecord "Small Record Index B-Tree Cell"]
  1465   1530           <p>
  1466   1531             If the cell record is larger than the maximum size identified by
  1467   1532             the formula above, then only the first part of the record is stored
  1468   1533             within the cell. The remainder is stored in an overflow-chain (see
  1469   1534             section <cite>overflow_page_chains</cite> for details). Following 
  1470   1535             the part of the record stored within the cell is the page number 
  1471   1536             of the first page in the overflow chain, stored as a 4 byte 
................................................................................
  1483   1548           <p>
  1484   1549             In the formula above, <i>usable-size</i> is the page-size
  1485   1550             in bytes less the number of unused bytes left at the end of every
  1486   1551             page (as read from byte offset 20 of the file header), and
  1487   1552             <i>max-embedded-fraction</i> and <i>min-embedded-fraction</i> are
  1488   1553             the values read from byte offsets 21 and 22 of the file header,
  1489   1554             respectively.
  1490         -        <center><img src="images/fileformat/indexlongrecord.gif">
  1491         -        <p><i>Figure <span class=fig id=figure_indexlongrecord></span> - 
  1492         -          Large Record Index B-Tree Cell.</i>
  1493         -        </center>
         1555  +        [Figure indexlongrecord.gif figure_indexlongrecord "Large Record Index B-Tree Cell"]
  1494   1556   
  1495   1557         <p class=req id=H30970>
  1496         -          <tcl>fileformat_import_requirement H30970</tcl>
         1558  +          [fileformat_import_requirement H30970]
  1497   1559   
  1498   1560         <p class=req id=H30980>
  1499         -          <tcl>fileformat_import_requirement H30980</tcl>
         1561  +          [fileformat_import_requirement H30980]
  1500   1562   
  1501   1563         <p class=req id=H30990>
  1502         -          <tcl>fileformat_import_requirement H30990</tcl>
         1564  +          [fileformat_import_requirement H30990]
  1503   1565   
  1504   1566         <p class=req id=H31000>
  1505         -          <tcl>fileformat_import_requirement H31000</tcl>
         1567  +          [fileformat_import_requirement H31000]
  1506   1568   
  1507   1569         <p class=req id=H31010>
  1508         -          <tcl>fileformat_import_requirement H31010</tcl>
         1570  +          [fileformat_import_requirement H31010]
  1509   1571   
  1510   1572         <p>
  1511   1573           Requirements H31010 and H30990 are similar to the algorithms 
  1512   1574           presented in the text above. However instead of 
  1513   1575           <i>min-embedded-fraction</i> and <i>max-embedded-fraction</i> the
  1514   1576           requirements use the constant values 32 and 64, as well-formed 
  1515   1577           database files are required by H30080 and H30070 to store these 
  1516   1578           values in the relevant database file header fields.
  1517   1579   
  1518         -    <h3 id=table_btrees>Table B-Trees</h3>
         1580  +    [h3 "Table B-Trees" table_btrees]
  1519   1581         <p>
  1520   1582           As noted in section <cite>fileformat_overview</cite>, table B-Trees
  1521   1583           store a set of unique 64-bit signed integer keys. Associated with
  1522   1584           each key is a database record. As with index B-Trees, the database
  1523   1585           file pages that make up a table B-Tree are organized into a tree
  1524   1586           structure with a single "root" page at the head of the tree.
  1525   1587         <p>
................................................................................
  1535   1597           contains a list of N-1 64-bit signed integer values in sorted order. 
  1536   1598           The keys are distributed throughout the tree such that for all internal
  1537   1599           tree nodes, integer I(n) is equal to the largest key value stored in
  1538   1600           the sub-tree headed by child page C(n) for values of n between 0 and
  1539   1601           N-2, inclusive. Additionally, all keys stored in the sub-tree headed
  1540   1602           by child page C(n+1) have values larger than that of I(n), for values
  1541   1603           of n in the same range.
  1542         -        <center><img src="images/fileformat/tabletree.gif">
  1543         -        <p><i>Figure <span class=fig id=figure_tabletree></span> - Table B-Tree Tree Structure.</i>
  1544         -        </center>
         1604  +
         1605  +        [Figure tabletree.gif figure_tabletree "Table B-Tree Tree Structure"]
         1606  +
  1545   1607         <p>
  1546   1608           Figure <cite>figure_tabletree</cite> depicts a table B-Tree containing
  1547   1609   	a contiguous set of 14 integer keys starting with 1. Each key <i>n</i>
  1548   1610   	has an associated database record R<i>n</i>. All the keys and their
  1549   1611   	associated records are stored in the leaf pages. The internal node
  1550   1612   	pages contain no database data, their only purpose is to provide
  1551   1613   	a way to navigate the tree structure.
  1552   1614   
  1553   1615         <p class=req id=H31020>
  1554         -          <tcl>fileformat_import_requirement H31020</tcl>
         1616  +          [fileformat_import_requirement H31020]
  1555   1617   
  1556   1618         <p class=req id=H31030>
  1557         -          <tcl>fileformat_import_requirement H31030</tcl>
         1619  +          [fileformat_import_requirement H31030]
  1558   1620   
  1559   1621         <p class=req id=H31040>
  1560         -          <tcl>fileformat_import_requirement H31040</tcl>
         1622  +          [fileformat_import_requirement H31040]
  1561   1623   
  1562   1624         <p class=req id=H31050>
  1563         -          <tcl>fileformat_import_requirement H31050</tcl>
         1625  +          [fileformat_import_requirement H31050]
  1564   1626   
  1565   1627         <p>
  1566   1628   	The precise way in which table B-Tree pages and cells are formatted is
  1567   1629           described in subsequent sections.
  1568   1630   
  1569         -      <h4 id=table_btree_content>Table B-Tree Content</h4>
         1631  +      [h4 "Table B-Tree Content" table_btree_content]
  1570   1632           <p>
  1571   1633   	  The database file contains one table B-Tree for each database table
  1572   1634   	  in the logical database. Although some data may be duplicated in
  1573   1635             index B-Tree structures, the table B-Tree is the primary location
  1574   1636             of table data.
  1575   1637           <p>
  1576   1638   	  The table B-Tree contains exactly one entry for each row in the
................................................................................
  1597   1659             2, then the values associated with the "missing" fields are 
  1598   1660   	  determined by the default value of the associated database table 
  1599   1661             columns.
  1600   1662   	  <span class=todo>Reference to CREATE TABLE syntax. How are default
  1601   1663             values determined?</span>
  1602   1664   
  1603   1665           <p class=req id=H31060>
  1604         -          <tcl>fileformat_import_requirement H31060</tcl>
         1666  +          [fileformat_import_requirement H31060]
  1605   1667   
  1606   1668           <p class=req id=H31070>
  1607         -          <tcl>fileformat_import_requirement H31070</tcl>
         1669  +          [fileformat_import_requirement H31070]
  1608   1670   
  1609   1671           <p class=req id=H31080>
  1610         -          <tcl>fileformat_import_requirement H31080</tcl>
         1672  +          [fileformat_import_requirement H31080]
  1611   1673   
  1612   1674           <p class=req id=H31090>
  1613         -          <tcl>fileformat_import_requirement H31090</tcl>
         1675  +          [fileformat_import_requirement H31090]
  1614   1676   
  1615   1677           <p>The following database properties discuss table B-Tree records 
  1616   1678              with implicit (default) values.
  1617   1679   
  1618   1680             <p class=req id=H31100>
  1619         -          <tcl>fileformat_import_requirement H31100</tcl>
         1681  +          [fileformat_import_requirement H31100]
  1620   1682   
  1621   1683             <p class=req id=H31110>
  1622         -          <tcl>fileformat_import_requirement H31110</tcl>
         1684  +          [fileformat_import_requirement H31110]
  1623   1685   
  1624   1686             <p class=req id=H31120>
  1625         -          <tcl>fileformat_import_requirement H31120</tcl>
         1687  +          [fileformat_import_requirement H31120]
  1626   1688   
  1627         -      <h4>Table B-Tree Page Format</h4>
         1689  +      [h4 "Table B-Tree Page Format"]
  1628   1690           <p>
  1629   1691             Table B-Tree structures use the same page format as index B-Tree 
  1630   1692             structures, described in section <cite>index_btree_page_format</cite>,
  1631   1693             with the following differences:
  1632   1694           <ul>
  1633   1695             <li>The first byte of the page-header, the "flags" field, is set to 
  1634   1696                 0x05 for internal tree node pages, and 0x0D for leaf pages.
................................................................................
  1637   1699             <li>The format of page 1 is the same as any other table B-Tree,
  1638   1700                 except that 100 bytes less than usual is available for content.
  1639   1701                 The first 100 bytes of page 1 is consumed by the database
  1640   1702                 file header.
  1641   1703           </ul>
  1642   1704   
  1643   1705         <p class=req id=H31130>
  1644         -          <tcl>fileformat_import_requirement H31130</tcl>
         1706  +          [fileformat_import_requirement H31130]
  1645   1707         <p class=req id=H31140>
  1646         -          <tcl>fileformat_import_requirement H31140</tcl>
         1708  +          [fileformat_import_requirement H31140]
  1647   1709           
  1648   1710         <p>
  1649   1711           Most of the requirements specified in section 
  1650   1712           <cite>index_btree_page_format</cite> also apply to table B-Tree 
  1651   1713           pages. The wording of the requirements make it clear when this is
  1652   1714           the case, either by refering to generic "B-Tree pages" or by
  1653   1715           explicitly stating that the statement applies to both "table and
  1654   1716           index B-Tree pages".
  1655   1717   
  1656         -      <h4 id=table_btree_cell_format>Table B-Tree Cell Format</h4>
         1718  +      [h4 "Table B-Tree Cell Format" table_btree_cell_format]
  1657   1719           <p>
  1658   1720             Cells stored on internal table B-Tree nodes consist of exactly two 
  1659   1721             fields. The associated child page number, stored as a 4-byte
  1660   1722             big-endian unsigned integer, followed by the 64-bit signed integer
  1661   1723             value, stored as a variable length integer (section 
  1662   1724             <cite>varint_format</cite>). This is depicted graphically in figure
  1663   1725             <cite>figure_tablenodecell</cite>.
  1664         -        <center><img src="images/fileformat/tablenodecell.gif">
  1665         -        <p><i>Figure <span class=fig id=figure_tablenodecell></span> - Table B-Tree Internal Node Cell.</i>
  1666         -        </center>
         1726  +        [Figure tablenodecell.gif figure_tablenodecell "Table B-Tree Internal Node Cell"]
  1667   1727           <p>
  1668   1728             Cells of table B-Tree leaf pages are required to store a 64-bit
  1669   1729             signed integer key and its associated database record. The first
  1670   1730             two fields of all table B-Tree leaf page cells are the size of
  1671   1731             the database record, stored as a <i>variable length integer</i>
  1672   1732             (see section <cite>varint_format</cite>), followed by the key
  1673   1733             value, also stored as a <i>variable length integer</i>. For 
................................................................................
  1680   1740           <p>
  1681   1741             bytes. Where <i>usable-size</i> is defined as the page-size
  1682   1742             in bytes less the number of unused bytes left at the end of every
  1683   1743             page (as read from byte offset 20 of the file header). 
  1684   1744             This scenario, where the entire record is
  1685   1745             stored within the B-Tree cell, is depicted in figure
  1686   1746             <cite>figure_tableshortrecord</cite>.
  1687         -        <center><img src="images/fileformat/tableshortrecord.gif">
  1688         -        <p><i>Figure <span class=fig id=figure_tableshortrecord></span> - Table B-Tree Small Record Leaf Node Cell.</i>
  1689         -        </center>
         1747  +        [Figure tableshortrecord.gif figure_tableshortrecord "Table B-Tree Small Record Leaf Node Cell"]
  1690   1748   
  1691   1749           <p>
  1692   1750             If the record is too large to be stored entirely within the B-Tree
  1693   1751             cell, then the first part of it is stored within the cell and the
  1694   1752             remainder in an overflow chain (see section
  1695   1753             <cite>overflow_page_chains</cite>). The size of the part of the 
  1696   1754             record stored within the B-Tree cell (<i>local-size</i> in figure
................................................................................
  1707   1765   </pre>
  1708   1766           <p>
  1709   1767             In this case, <i>min-embedded-fraction</i> is the value read from
  1710   1768             byte offset 22 of the file header. The layout of the cell in this
  1711   1769             case, when an overflow-chain is required, is shown in figure
  1712   1770             <cite>figure_tablelongrecord</cite>.
  1713   1771   
  1714         -        <center><img src="images/fileformat/tablelongrecord.gif">
  1715         -        <p><i>Figure <span class=fig id=figure_tablelongrecord></span> - Table B-Tree Large Record Leaf Node Cell.</i>
  1716         -        </center>
         1772  +        [Figure tablelongrecord.gif figure_tablelongrecord "Table B-Tree Large Record Leaf Node Cell"]
  1717   1773   
  1718   1774           <p>
  1719   1775             If the leaf page is page 1, then the value of <i>usable-size</i> is
  1720   1776             as it would be for any other B-Tree page, even though the actual
  1721   1777             usable size is 100 bytes less than this for page 1 (because the
  1722   1778             first 100 bytes of the page is consumed by the database file
  1723   1779             header).
................................................................................
  1724   1780   
  1725   1781           <p>
  1726   1782             The following requirements describe the format of table B-Tree 
  1727   1783             cells, and the distribution thereof between B-Tree and overflow
  1728   1784             pages.
  1729   1785   
  1730   1786           <p class=req id=H31150>
  1731         -          <tcl>fileformat_import_requirement H31150</tcl>
         1787  +          [fileformat_import_requirement H31150]
  1732   1788   
  1733   1789           <p class=req id=H31160>
  1734         -          <tcl>fileformat_import_requirement H31160</tcl>
         1790  +          [fileformat_import_requirement H31160]
  1735   1791   
  1736   1792           <p class=req id=H31170>
  1737         -          <tcl>fileformat_import_requirement H31170</tcl>
         1793  +          [fileformat_import_requirement H31170]
  1738   1794   
  1739   1795           <p class=req id=H31180>
  1740         -          <tcl>fileformat_import_requirement H31180</tcl>
         1796  +          [fileformat_import_requirement H31180]
  1741   1797   
  1742   1798           <p class=req id=H31190>
  1743         -          <tcl>fileformat_import_requirement H31190</tcl>
         1799  +          [fileformat_import_requirement H31190]
  1744   1800           
  1745   1801           <p>
  1746   1802             Requirement H31190 is very similar to the algorithm presented in
  1747   1803             the text above. Instead of <i>min-embedded-fraction</i>, it uses
  1748   1804             the constant value 32, as well-formed database files are required
  1749   1805             by H30090 to store this value in the relevant database file 
  1750   1806             header field.
  1751   1807   
  1752         -    <h3 id="overflow_page_chains">Overflow Page Chains</h3>
         1808  +    [h3 "Overflow Page Chains" "overflow_page_chains"]
  1753   1809         <p>
  1754   1810           Sometimes, a database record stored in either an index or table 
  1755   1811           B-Trees is too large to fit entirely within a B-Tree cell. In this
  1756   1812           case part of the record is stored within the B-Tree cell and the
  1757   1813           remainder stored on one or more overflow pages. The overflow pages
  1758   1814           are chained together using a singly linked list. The first 4 bytes
  1759   1815           of each overflow page is a big-endian unsigned integer value 
  1760   1816           containing the page number of the next page in the list. The 
  1761   1817           remaining usable database page space is available for record data.
  1762         -      <center><img src="images/fileformat/overflowpage.gif">
  1763         -      <p><i>Figure <span class=fig id=figure_overflowpage></span> - Overflow Page Format.</i>
  1764         -      </center>
         1818  +
         1819  +        [Figure overflowpage.gif figure_overflowpage "Overflow Page Format"]
         1820  +
  1765   1821         <p>
  1766   1822           The scenarios in which overflow pages are required and the number
  1767   1823           of bytes stored within the B-Tree cell in each are described for
  1768   1824           index and table B-Trees in sections 
  1769   1825           <cite>index_btree_cell_format</cite> and
  1770   1826           <cite>table_btree_cell_format</cite> respectively. In each case 
  1771   1827           the B-Tree cell also stores the page number of the first page in
................................................................................
  1784   1840           Each overflow page except for the last one in the linked list 
  1785   1841           contains <i>available-space</i> bytes of record data. The last
  1786   1842           page in the list contains the remaining data, starting at byte
  1787   1843           offset 4. The value of the "next page" field on the last page
  1788   1844           in an overflow chain is undefined.
  1789   1845   
  1790   1846         <p class=req id=H31200>
  1791         -          <tcl>fileformat_import_requirement H31200</tcl>
         1847  +          [fileformat_import_requirement H31200]
  1792   1848   
  1793   1849         <p class=req id=H31210>
  1794         -          <tcl>fileformat_import_requirement H31210</tcl>
         1850  +          [fileformat_import_requirement H31210]
  1795   1851   
  1796   1852         <p class=req id=H31220>
  1797         -          <tcl>fileformat_import_requirement H31220</tcl>
         1853  +          [fileformat_import_requirement H31220]
  1798   1854   
  1799   1855         <p class=req id=H31230>
  1800         -          <tcl>fileformat_import_requirement H31230</tcl>
         1856  +          [fileformat_import_requirement H31230]
  1801   1857   
  1802         -  <h2 id=free_page_list>The Free Page List</h2>
         1858  +  [h2 "The Free Page List" free_page_list]
  1803   1859       <p>
  1804   1860         Sometimes, after deleting data from the database, SQLite removes pages
  1805   1861         from B-Tree structures. If these pages are not immediately required
  1806   1862         for some other purpose, they are placed on the free page list. The
  1807   1863         free page list contains those pages that are not currently being
  1808   1864         used to store any valid data.
  1809   1865       <p>
................................................................................
  1827   1883       <pre>
  1828   1884           <i>max-leaf-pointers</i> := (<i>usable-size</i> - 8) / 4
  1829   1885   </pre>
  1830   1886       <p>
  1831   1887         pointers, where <i>usable-size</i> is defined as the page-size in bytes
  1832   1888         less the number of unused bytes left at the end of every page (as read
  1833   1889         from byte offset 20 of the file header).
  1834         -    <center><img src="images/fileformat/freelistpage.gif">
  1835         -    <p><i>Figure <span class=fig id=figure_freelistpage></span> - Free List Trunk Page Format.</i>
  1836         -    </center>
         1890  +
         1891  +      [Figure freelistpage.gif figure_freelistpage "Free List Trunk Page Format"]
  1837   1892       <p>
  1838   1893         All trunk pages in the free-list except for the first contain the 
  1839   1894         maximum possible number of references to leaf pages. <span class=todo>Is this actually true in an auto-vacuum capable database?</span> The page number
  1840   1895         of the first page in the linked list of free-list trunk pages is 
  1841   1896         stored as a 4-byte big-endian unsigned integer at offset 32 of the
  1842   1897         file header (section <cite>file_header</cite>).
  1843   1898   
  1844   1899       <p class=req id=H31240>
  1845         -          <tcl>fileformat_import_requirement H31240</tcl>
         1900  +          [fileformat_import_requirement H31240]
  1846   1901   
  1847   1902       <p class=req id=H31250>
  1848         -          <tcl>fileformat_import_requirement H31250</tcl>
         1903  +          [fileformat_import_requirement H31250]
  1849   1904   
  1850   1905       <p class=req id=H31260>
  1851         -          <tcl>fileformat_import_requirement H31260</tcl>
         1906  +          [fileformat_import_requirement H31260]
  1852   1907   
  1853   1908       <p class=req id=H31270>
  1854         -          <tcl>fileformat_import_requirement H31270</tcl>
         1909  +          [fileformat_import_requirement H31270]
  1855   1910   
  1856   1911       <p class=req id=H31280>
  1857         -          <tcl>fileformat_import_requirement H31280</tcl>
         1912  +          [fileformat_import_requirement H31280]
  1858   1913   
  1859   1914       <p class=req id=H31290>
  1860         -          <tcl>fileformat_import_requirement H31290</tcl>
         1915  +          [fileformat_import_requirement H31290]
  1861   1916   
  1862   1917       <p class=req id=H31300>
  1863         -          <tcl>fileformat_import_requirement H31300</tcl>
         1918  +          [fileformat_import_requirement H31300]
  1864   1919   
  1865   1920       <p>The following statements govern the two 4-byte big-endian integers
  1866   1921          associated with the <i>free page list</i> structure in the database
  1867   1922          file header.
  1868   1923   
  1869   1924       <p class=req id=H31310>
  1870         -          <tcl>fileformat_import_requirement H31310</tcl>
         1925  +          [fileformat_import_requirement H31310]
  1871   1926   
  1872   1927       <p class=req id=H31320>
  1873         -          <tcl>fileformat_import_requirement H31320</tcl>
         1928  +          [fileformat_import_requirement H31320]
  1874   1929     
  1875   1930   
  1876         -  <h2 id=pointer_map_pages>Pointer Map Pages</h2>
         1931  +  [h2 "Pointer Map Pages" pointer_map_pages]
  1877   1932       <p>
  1878   1933         Pointer map pages are only present in auto-vacuum capable databases.
  1879   1934         A database is an auto-vacuum capable database if the value stored 
  1880   1935         at byte offset 52 of the file-header is non-zero.
  1881   1936       <p>
  1882   1937         If they are present, the pointer-map pages together form a lookup 
  1883   1938         table that can be used to determine the type and "parent page" of
  1884   1939         any page in the database, given its page number. The lookup table
  1885   1940         classifies pages into the following categories:
  1886         -    <table class=striped>
  1887         -      <tr><th>Page Type <th>Byte Value <th>Description
  1888         -      <tr><td style="white-space:nowrap">B-Tree Root Page<td>0x01
         1941  +    [Table]
         1942  +      [Tr]<th>Page Type <th>Byte Value <th>Description
         1943  +      [Tr]<td style="white-space:nowrap">B-Tree Root Page<td>0x01
  1889   1944             <td>The page is the root page of a table or index B-Tree structure.
  1890   1945                 There is no parent page number in this case, the value stored
  1891   1946                 in the pointer map lookup table is always zero.
  1892         -      <tr><td>Free Page<td>0x02
         1947  +      [Tr]<td>Free Page<td>0x02
  1893   1948             <td>The page is part of the free page list (section
  1894   1949                 <cite>free_page_list</cite>). There is no parent page in this
  1895   1950                 case, zero is stored in the lookup table instead of a parent
  1896   1951                 page number.
  1897         -      <tr><td>Overflow type 1<td>0x03
         1952  +      [Tr]<td>Overflow type 1<td>0x03
  1898   1953             <td>The page is the first page in an overflow chain. The parent
  1899   1954                 page is the B-Tree page containing the B-Tree cell to which
  1900   1955                 the overflow chain belongs.
  1901         -      <tr><td style="white-space:nowrap">Overflow type 2<td>0x04
         1956  +      [Tr]<td style="white-space:nowrap">Overflow type 2<td>0x04
  1902   1957             <td>The page is part of an overflow chain, but is not the first
  1903   1958                 page in that chain. The parent page is the previous page in
  1904   1959                 the overflow chain linked-list.
  1905         -      <tr><td>B-Tree Page<td>0x05
         1960  +      [Tr]<td>B-Tree Page<td>0x05
  1906   1961             <td>The page is part of a table or index B-Tree structure, and is 
  1907   1962                 not an overflow page or root page. The parent page is the page
  1908   1963                 containing the parent tree node in the B-Tree structure.
  1909   1964       </table>
  1910   1965       <p>
  1911   1966         Pointer map pages themselves do not appear in the pointer-map lookup
  1912   1967         table. Page 1 does not appear in the pointer-map lookup table either.
  1913   1968   
  1914         -    <center><img src="images/fileformat/pointermapentry.gif">
  1915         -    <p><i>Figure <span class=fig id=figure_pointermapentry></span> - Pointer Map Entry Format.</i>
  1916         -    </center>
         1969  +    [Figure pointermapentry.gif figure_pointermapentry "Pointer Map Entry Format"]
  1917   1970       <p>
  1918   1971         Each pointer-map lookup table entry consumes 5 bytes of space. 
  1919   1972         The first byte of each entry indicates the page type, according to the 
  1920   1973         key described in the table above. The following 4 bytes store the 
  1921   1974         parent page number as a big-endian unsigned integer. This format is
  1922   1975         depicted in figure <cite>figure_pointermapentry</cite>. Each 
  1923   1976         pointer-map page may therefore contain:
................................................................................
  1945   1998         database file:
  1946   1999       <pre>
  1947   2000           <i>pointer-map-page-number</i> := 2 + <i>n</i> * <i>num-entries</i>
  1948   2001   </pre>
  1949   2002   
  1950   2003   
  1951   2004       <p class=req id=H31330>
  1952         -          <tcl>fileformat_import_requirement H31330</tcl>
         2005  +          [fileformat_import_requirement H31330]
  1953   2006   
  1954   2007       <p class=req id=H31340>
  1955         -          <tcl>fileformat_import_requirement H31340</tcl>
         2008  +          [fileformat_import_requirement H31340]
  1956   2009   
  1957   2010       <p class=req id=H31350>
  1958         -          <tcl>fileformat_import_requirement H31350</tcl>
         2011  +          [fileformat_import_requirement H31350]
  1959   2012   
  1960   2013       <p class=req id=H31360>
  1961         -          <tcl>fileformat_import_requirement H31360</tcl>
         2014  +          [fileformat_import_requirement H31360]
  1962   2015   
  1963   2016       <p class=req id=H31370>
  1964         -          <tcl>fileformat_import_requirement H31370</tcl>
         2017  +          [fileformat_import_requirement H31370]
  1965   2018   
  1966   2019       <p>
  1967   2020         The following requirements govern the content of pointer-map entries.
  1968   2021   
  1969   2022       <p class=req id=H31380>
  1970         -          <tcl>fileformat_import_requirement H31380</tcl>
         2023  +          [fileformat_import_requirement H31380]
  1971   2024       <p class=req id=H31390>
  1972         -          <tcl>fileformat_import_requirement H31390</tcl>
         2025  +          [fileformat_import_requirement H31390]
  1973   2026       <p class=req id=H31400>
  1974         -          <tcl>fileformat_import_requirement H31400</tcl>
         2027  +          [fileformat_import_requirement H31400]
  1975   2028       <p class=req id=H31410>
  1976         -          <tcl>fileformat_import_requirement H31410</tcl>
         2029  +          [fileformat_import_requirement H31410]
  1977   2030       <p class=req id=H31420>
  1978         -          <tcl>fileformat_import_requirement H31420</tcl>
         2031  +          [fileformat_import_requirement H31420]
  1979   2032   
  1980         -<h1 id=journal_file_format>Journal File Format</h1>
         2033  +[h1 "Journal File Format" journal_file_format]
  1981   2034   
  1982   2035       <p>
  1983   2036         This section describes the format used by an SQLite <i>journal file</i>.
  1984   2037   
  1985   2038       <p>
  1986   2039         A journal file consists of one or more <i>journal headers</i>, zero
  1987   2040         or more <i>journal records</i> and optionally a <i>master journal
................................................................................
  1991   2044         second set of zero or more <i>journal records</i> and so on. There
  1992   2045         is no limit to the number of <i>journal headers</i> a journal file
  1993   2046         may contain. Following the <i>journal headers</i> and their accompanying
  1994   2047         sets of <i>journal records</i> may be the optional <i>master journal
  1995   2048         pointer</i>. Or, the file may simply end following the final <i>journal
  1996   2049         record</i>.
  1997   2050   
  1998         -    <h2 id=journal_header_format>Journal Header Format</h2>
         2051  +    [h2 "Journal Header Format" journal_header_format]
  1999   2052   
  2000   2053       <p>
  2001   2054         A <i>journal header</i> is <i>sector-size</i> bytes in size, where <i>
  2002   2055         sector-size</i> is the value returned by the xSectorSize method of
  2003   2056         the file handle opened on the database file. Only the first 28 bytes
  2004   2057         of the <i>journal header</i> are used, the remainder may contain garbage
  2005   2058         data. The first 28 bytes of each <i>journal header</i> consists of an 
  2006   2059         eight byte block set to a well-known value, followed by five big-endian 
  2007   2060         32-bit unsigned integer fields.
  2008   2061        
  2009         -    <center><img src="images/fileformat/journal_header.gif">
  2010         -    <p><i>Figure <span class=fig id=figure_journal_header></span> - Journal Header Format</i>
  2011         -      </center>
         2062  +    [Figure journal_header.gif figure_journal_header "Journal Header Format"]
  2012   2063   
  2013   2064       <p>
  2014   2065         Figure <cite>figure_journal_header</cite> graphically depicts the layout
  2015   2066         of a <i>journal header</i>. The individual fields are described in
  2016   2067         the following table. The offsets in the 'byte offset' column of the
  2017   2068         table are relative to the start of the <i>journal header</i>.
  2018   2069   
  2019         -    <table class=striped>
  2020         -      <tr><th>Byte offset<th>Size in bytes<th width=100%>Description
  2021         -      <tr><td>0<td>8<td>The <b>journal magic</b> field always contains a
         2070  +    [Table]
         2071  +      [Tr]<th>Byte offset<th>Size in bytes<th width=100%>Description
         2072  +      [Tr]<td>0<td>8<td>The <b>journal magic</b> field always contains a
  2022   2073                           well-known 8-byte string value used to identify SQLite
  2023   2074                           journal files. The well-known sequence of byte values
  2024   2075                           is:
  2025   2076                           <pre>0xd9 0xd5 0x05 0xf9 0x20 0xa1 0x63 0xd7</pre>
  2026         -      <tr><td>8<td>4<td>This field, the <b>record count</b>, is set to the
         2077  +      [Tr]<td>8<td>4<td>This field, the <b>record count</b>, is set to the
  2027   2078                           number of <i>journal records</i> that follow this
  2028   2079                           <i>journal header</i> in the <i>journal file</i>.
  2029         -      <tr><td>12<td>4<td>The <b>checksum initializer</b> field is set to a 
         2080  +      [Tr]<td>12<td>4<td>The <b>checksum initializer</b> field is set to a 
  2030   2081                            pseudo-random value. It is used as part of the
  2031   2082                            algorithm to calculate the checksum for all <i>journal
  2032   2083                            records</i> that follow this <i>journal header</i>.
  2033         -      <tr><td>16<td>4<td>This field, the <b>database page count</b>, is set
         2084  +      [Tr]<td>16<td>4<td>This field, the <b>database page count</b>, is set
  2034   2085                            to the number of pages that the <i>database file</i>
  2035   2086                            contained before any modifications associated with
  2036   2087                            <i>write transaction</i> are applied.
  2037         -      <tr><td>20<td>4<td>This field, the <b>sector size</b>, is set to the
         2088  +      [Tr]<td>20<td>4<td>This field, the <b>sector size</b>, is set to the
  2038   2089                            <i>sector size</i> of the device on which the 
  2039   2090                            <i>journal file</i> was created, in bytes. This value
  2040   2091                            is required when reading the journal file to determine
  2041   2092                            the size of each <i>journal header</i>.
  2042         -      <tr><td>24<td>4<td>The <b>page size</b> field contains the database page
         2093  +      [Tr]<td>24<td>4<td>The <b>page size</b> field contains the database page
  2043   2094                            size used by the corresponding <i>database file</i>
  2044   2095                            when the <i>journal file</i> was created, in bytes.
  2045   2096       </table>
  2046   2097   
  2047   2098       <p>
  2048   2099         All <i>journal headers</i> are positioned in the file so that they 
  2049   2100         start at a <i>sector size</i> aligned offset. To achieve this, unused
  2050   2101         space may be left between the start of the second and subsequent
  2051   2102         <i>journal headers</i> and the end of the <i>journal records</i>
  2052   2103         associated with the previous header.
  2053   2104   
  2054         -  <h2 id=journal_record_format>Journal Record Format</h2>
         2105  +  [h2 "Journal Record Format" journal_record_format]
  2055   2106   
  2056   2107       <p>
  2057   2108         Each <i>journal record</i> contains the original data for a database page
  2058   2109         modified by the <i>write transaction</i>. If a rollback is required, then
  2059   2110         this data may be used to restore the contents of the database page to the
  2060   2111         state it was in before the <i>write transaction</i> was started.
  2061   2112   
  2062         -    <center><img src="images/fileformat/journal_record.gif">
  2063         -    <p><i>Figure <span class=fig id=figure_journal_record></span> - Journal Record Format</i>
  2064         -      </center>
         2113  +    [Figure journal_record.gif figure_journal_record "Journal Record Format"]
  2065   2114   
  2066   2115       <p>
  2067   2116         A <i>journal record</i>, depicted graphically by figure
  2068   2117         <cite>figure_journal_record</cite>, contains three fields, as described
  2069   2118         in the following table. Byte offsets are relative to the start of the
  2070   2119         <i>journal record</i>.
  2071   2120   
  2072         -    <table class=striped>
  2073         -      <tr><th>Byte offset<th>Size in bytes<th width=100%>Description
  2074         -      <tr><td>0<td>4<td>The page number of the database page associated with
         2121  +    [Table]
         2122  +      [Tr]<th>Byte offset<th>Size in bytes<th width=100%>Description
         2123  +      [Tr]<td>0<td>4<td>The page number of the database page associated with
  2075   2124                           this <i>journal record</i>, stored as a 4 byte
  2076   2125                           big-endian unsigned integer.
  2077         -      <tr><td>4<td><i>page-size<td>
         2126  +      [Tr]<td>4<td><i>page-size<td>
  2078   2127                           This field contains the original data for the page,
  2079   2128                           exactly as it appeared in the database file before the
  2080   2129                           <i>write transaction</i> began.
  2081         -      <tr><td style="white-space: nowrap">4 + <i>page-size</i><td>4<td>
         2130  +      [Tr]<td style="white-space: nowrap">4 + <i>page-size</i><td>4<td>
  2082   2131                           This field contains a checksum value, calculated based
  2083   2132                           on the contents of the journaled database page data
  2084   2133                           (the previous field) and the values stored in the
  2085   2134                           <i>checksum initializer</i> field of the preceding
  2086   2135                           <i>journal header</i>.
  2087   2136       </table>
  2088   2137   
  2089   2138       <p>
  2090   2139         The set of <i>journal records</i> that follow a <i>journal header</i>
  2091   2140         in a <i>journal file</i> are packed tightly together. There are no
  2092   2141         alignment requirements for <i>journal records</i> as there are for
  2093   2142         <i>journal headers</i>.
  2094   2143   
  2095         -  <h2>Master Journal Pointer</h2>
         2144  +  [h2 "Master Journal Pointer"]
  2096   2145   
  2097   2146       <p>
  2098   2147         To support <i>atomic</i> transactions that modify more than one 
  2099   2148         database file, SQLite sometimes includes a <i>master journal pointer</i>
  2100   2149         record in a <i>journal file</i>. A <i>master journal pointer</i>
  2101   2150         contains the name of a <i>master journal-file</i> along with a 
  2102   2151         check-sum and some well-known values that allow the 
................................................................................
  2108   2157         journal pointer</i> is always positioned at a <i>sector size</i> 
  2109   2158         aligned offset. If the <i>journal record</i> or <i>journal header</i>
  2110   2159         that appears immediately before the <i>master journal pointer</i> does
  2111   2160         not end at an aligned offset, then unused space is left between the
  2112   2161         end of the <i>journal record</i> or <i>journal header</i> and the start
  2113   2162         of the <i>master journal pointer</i>.
  2114   2163   
  2115         -    <center><img src="images/fileformat/master_journal_ptr.gif">
  2116         -    <p><i>Figure <span class=fig id=figure_master_journal_ptr></span> - Master Journal Pointer Format</i>
  2117         -      </center>
         2164  +    [Figure master_journal_ptr.gif figure_master_journal_ptr "Master Journal Pointer Format"]
  2118   2165   
  2119   2166       <p>
  2120   2167         A <i>master journal pointer</i>, depicted graphically by figure
  2121   2168         <cite>figure_master_journal_ptr</cite>, contains five fields, as 
  2122   2169         described in the following table. Byte offsets are relative to the 
  2123   2170         start of the <i>master journal pointer</i>.
  2124   2171   
  2125         -    <table class=striped>
  2126         -      <tr><th>Byte offset<th>Size in bytes<th width=100%>Description
  2127         -      <tr><td>0<td>4<td>This field, the <b>locking page number</b>, is always
         2172  +    [Table]
         2173  +      [Tr]<th>Byte offset<th>Size in bytes<th width=100%>Description
         2174  +      [Tr]<td>0<td>4<td>This field, the <b>locking page number</b>, is always
  2128   2175                  set to the page number of the database <i>locking page</i>
  2129   2176                  stored as a 4-byte big-endian integer. The <i>locking page</i>
  2130   2177                  is the page that begins at byte offset 2<super>30</super> of the
  2131   2178                  database file. Even if the database file is large enough to
  2132   2179                  contain the <i>locking page</i>, the <i>locking page</i> is
  2133   2180                  never used to store any data and so the first four bytes of of a
  2134   2181                  valid <i>journal record</i> will never contain this value.
  2135   2182   
  2136         -      <tr><td>4<td><i>name-length</i><td>
         2183  +      [Tr]<td>4<td><i>name-length</i><td>
  2137   2184                  The <b>master journal name</b> field contains the name of the
  2138   2185                  master journal file, encoded as a utf-8 string. There is no
  2139   2186                  nul-terminator appended to the string.
  2140         -      <tr><td>4 + <i>name-length</i><td><i>4<td>
         2187  +      [Tr]<td>4 + <i>name-length</i><td><i>4<td>
  2141   2188                  The <b>name-length</b> field contains the length of the 
  2142   2189                  previous field in bytes, formatted as a 4-byte big-endian 
  2143   2190                  unsigned integer.
  2144         -      <tr><td>8 + <i>name-length</i><td><i>4<td>
         2191  +      [Tr]<td>8 + <i>name-length</i><td><i>4<td>
  2145   2192                  The <b>checksum</b> field contains a checksum value stored as
  2146   2193                  a 4-byte big-endian signed integer. The checksum value is
  2147   2194                  calculated as the sum of the bytes that make up the <i>
  2148   2195                  master journal name</i> field, interpreting each byte as
  2149   2196                  an 8-bit signed integer.
  2150         -      <tr><td style="white-space: nowrap">12 + <i>name-length</i><td><i>8<td>
         2197  +      [Tr]<td style="white-space: nowrap">12 + <i>name-length</i><td><i>8<td>
  2151   2198                  Finally, the <b>journal magic</b> field always contains a
  2152   2199                  well-known 8-byte string value; the same value stored in the
  2153   2200                  first 8 bytes of a <i>journal header</i>. The well-known
  2154   2201                  sequence of bytes is:
  2155   2202                    <pre>0xd9 0xd5 0x05 0xf9 0x20 0xa1 0x63 0xd7</pre>
  2156   2203       </table>
  2157   2204   
  2158   2205   <!--
  2159         -<h1 id="database_file_traversal">Database File Structure Traversal</h1>
         2206  +\[h1 "Database File Structure Traversal" "database_file_traversal"]
  2160   2207   
  2161         -  <h2>B-Tree Cursors</h2>
         2208  +  \[h2 "B-Tree Cursors"]
  2162   2209   
  2163   2210     <h2>B-Tree Access Strategies</h2>
  2164   2211       <h3>Full Linear Scan</h3>
  2165   2212       <h3>Seek to Value</h3>
  2166   2213       <h3>Range Scan</h3>
  2167   2214   
  2168   2215     <h2>Retrieving Record Values</h2>
  2169   2216   
  2170         -<h1 id="database_file_manipulation">Database File Manipulation</h1>
         2217  +\[h1 "Database File Manipulation" "database_file_manipulation"]
  2171   2218   
  2172   2219     <h2>Creating a Database</h2>
  2173   2220   
  2174   2221     <h2>Table B-Trees</h2>
  2175   2222       <h3>Creating a new Table B-Tree</h3>
  2176   2223       <h3>Deleting a Table B-Tree</h3>
  2177   2224       <h3>Adding an Entry to a Table B-Tree</h3>
................................................................................
  2186   2233     <h2>Overflow Chains</h2>
  2187   2234   
  2188   2235     <h2>Allocating/Deallocating Pages</h2>
  2189   2236       <h2>Allocating a Page</h2>
  2190   2237       <h2>Deallocating a Page</h2>
  2191   2238   
  2192   2239     <h2>Auto-Vacuum Commit Operations</h2>
  2193         --->
  2194   2240   
  2195         -<!--
  2196   2241     <p>
  2197   2242       The previous section described the format of a valid SQLite database
  2198   2243       file. This section describes the way in which a database file is
  2199   2244       transitioned between valid states by SQLite to effect various 
  2200   2245       operations, for example creating a table or inserting a database
  2201   2246       record.
  2202   2247     <p>
................................................................................
  2239   2284     <p class=todo>
  2240   2285       Fix this XXX reference. And add any other references to SQLiteRT
  2241   2286       requirements documents that may specify requirements in terms of these
  2242   2287       operations.
  2243   2288     <p class=todo>
  2244   2289       VACUUM? Auto-vacuum steps?
  2245   2290   
  2246         -  <h2 id=database_initialization>Database Creation/Initialization</h2>
         2291  +  \[h2 "Database Creation/Initialization" database_initialization]
  2247   2292       <p>
  2248   2293         As noted in section <cite>database_file_format</cite> a zero-length 
  2249   2294         file is a valid empty SQLite database. The first time such a
  2250   2295         database is written to, SQLite initializes the the first page of
  2251   2296         the database file as described by the following requirements, creating
  2252   2297         a one-page empty SQLite database file.
  2253   2298   
................................................................................
  2274   2319         Some requirement to say where the initial page-size comes from. Probably
  2275   2320         a reference to the SQL level requirements documenting the page-size
  2276   2321         pragma.
  2277   2322       <p class=todo>
  2278   2323         Requirements for the other fields of the database header. Also to
  2279   2324         describe how the part of page 1 after the header is initialized.
  2280   2325   
  2281         -  <h2 id=database_parameters>Setting Database Parameters</h2>
         2326  +  \[h2 "Setting Database Parameters" database_parameters]
  2282   2327       <p>
  2283   2328         The database file-header contains three values that the system may
  2284   2329         be required to update in response to the execution of SQL pragma
  2285   2330         statements. These are:
  2286   2331       <ul>
  2287   2332         <li>The default pager-cache size,
  2288   2333         <li>The user-cookie value,
................................................................................
  2303   2348         integer starting at byte offset 60 of the database file.
  2304   2349       <p class=req>
  2305   2350         When required to set the incremental vacuum flag of a database, the
  2306   2351         system shall store the new value as a 4-byte big-endian unsigned 
  2307   2352         integer starting at byte offset 64 of the database file.
  2308   2353   
  2309   2354     <h2>Creating and Deleting B-Tree Structures</h2>
  2310         -    <h3 id=btree_creation>Table/Index Creation</h3>
         2355  +    \[h3 "Table/Index Creation" btree_creation]
  2311   2356         <p class=req>
  2312   2357           When a new table or index is added to a non auto-vacuum database file,
  2313   2358           the system shall initialize a newly allocated database page as the root
  2314   2359           page of an empty table or index B-Tree, respectively.
  2315   2360         <p class=todo>
  2316   2361           Requirements describing in detail how an empty root page is initialized.
  2317   2362   
................................................................................
  2359   2404         manipulate B-Tree structures within a database file. Various 
  2360   2405         operations at the SQL level require the system to insert or remove
  2361   2406         entries from both table and index B-Trees. <span class=todo>It would be
  2362   2407         good to reference some other requirements document here.</span>
  2363   2408   
  2364   2409       <h3>Inserting Records</h3>
  2365   2410   
  2366         -    <h4>Table B-Tree Inserts</h4>
         2411  +    \[h4 "Table B-Tree Inserts"]
  2367   2412   
  2368   2413         <p class=req>
  2369   2414           When required to insert a new entry into a table B-Tree, the system
  2370   2415           shall format a new table B-Tree leaf node cell containing the 
  2371   2416           integer key value and accompanying database record, and add the
  2372   2417           new cell to a leaf node of the table B-Tree structure.
  2373   2418         <p>
................................................................................
  2386   2431             B-Tree constructor consists of more than one page, then the system
  2387   2432             shall attempt to insert the new cell into the leaf node page that
  2388   2433             currently contains the largest key value that is smaller than
  2389   2434             the key value of the cell being inserted.
  2390   2435           <p class=todo>
  2391   2436             Finish this.
  2392   2437   
  2393         -    <h4>Index B-Tree Inserts</h4>
         2438  +    \[h4 "Index B-Tree Inserts"]
  2394   2439           <p class=todo>
  2395   2440             Finish this.
  2396   2441     
  2397   2442       <h3>Removing Records</h3>
  2398   2443           <p class=todo>
  2399   2444             Finish this.
  2400   2445   
................................................................................
  2435   2480       </ul>
  2436   2481       <p>
  2437   2482         The requirements found in this section specify the manner in which
  2438   2483         the system is required to manipulate the contents of database 
  2439   2484         free-list pages to achieve this are found in section
  2440   2485         <cite>page_removal</cite>.
  2441   2486   
  2442         -    <h3 id=page_allocation>Page Allocation</h3>
         2487  +    \[h3 "Page Allocation" page_allocation]
  2443   2488        <p>
  2444   2489          If the database free-list is empty, then the new page is allocated
  2445   2490          by extending the database file:
  2446   2491   
  2447   2492        <p class=req>
  2448   2493          When SQLite allocates a new database page, if the database free 
  2449   2494          page list is completely empty, the page shall be allocated by 
................................................................................
  2494   2539            now empty.
  2495   2540          <p class=subreq>
  2496   2541            After removing a page from the free-list, SQLite shall update 
  2497   2542            the 4-byte integer value stored at byte offset 36 of the database 
  2498   2543            file header to reflect the new number of pages in the database 
  2499   2544            free page list (one less than before).
  2500   2545   
  2501         -    <h3 id=page_deallocation>Page Deallocation</h3>
         2546  +    \[h3 "Page Deallocation" page_deallocation]
  2502   2547         <p class=req>
  2503   2548           If SQLite is required to free a database page when the free-list 
  2504   2549           is complete empty, or when the first page of the free-list trunk
  2505   2550           is completely full, SQLite shall use the freed page as the new 
  2506   2551           head of the free-list trunk. 
  2507   2552           <p class=subreq>
  2508   2553             When a newly freed page is made the head of the free-list trunk,
................................................................................
  2526   2571           page in the free-list trunk.
  2527   2572         <p class=req>
  2528   2573           After removing a page from the free-list, SQLite shall update 
  2529   2574           the 4-byte integer value stored at byte offset 36 of the database 
  2530   2575           file header to reflect the new number of pages in the database 
  2531   2576           free page list (one less than before).
  2532   2577   
  2533         -    <h3 id=page_removal>Removing a Page From The Free List</h3>
         2578  +    \[h3 "Removing a Page From The Free List" page_removal]
  2534   2579         <p class=req>
  2535   2580           When the system is required to remove a specific page from the 
  2536   2581           database free-list, and that page is a free-list leaf page, the
  2537   2582           system shall remove the specified leaf page number from the
  2538   2583           relevant trunk page.
  2539   2584         <p class=req>
  2540   2585           When the system is required to remove a specific page from the 
................................................................................
  2545   2590           When the system is required to remove a specific page from the 
  2546   2591           database free-list, and that page is a non-empty free-list trunk 
  2547   2592           page, the system shall move the contents of the trunk page
  2548   2593           to its first leaf page, remove the first leaf entry from the new
  2549   2594           trunk page, then link the new trunk page into the free-list trunk
  2550   2595           in place of the page being removed.
  2551   2596   
  2552         -    <h3 id=incremental_vacuum>Database Reorganization (auto-vacuum)</h3>
         2597  +    \[h3 "Database Reorganization (auto-vacuum)" incremental_vacuum]
  2553   2598         <p class=todo>
  2554   2599           Requirements describing incremental vacuum steps. And on-commit
  2555   2600           handling in auto-vacuum databases.
  2556   2601   -->
  2557   2602   
  2558         -<h1>References</h1>
         2603  +[h1 References]
  2559   2604   
  2560   2605     <table id="refs" style="width:auto; margin: 1em 5ex">
  2561         -    <tr><td style="width:5ex" id="ref_comer_btree">[1]<td>
         2606  +    <tr><td style="width:5ex" id="ref_comer_btree">\[1\]<td>
  2562   2607        Douglas Comer, <u>Ubiquitous B-Tree</u>, ACM Computing Surveys (CSUR),
  2563   2608        v.11 n.2, pages 121-137, June 1979.
  2564         -    <tr><td style="width:5ex" id="ref_knuth_btree">[2]<td>
         2609  +    <tr><td style="width:5ex" id="ref_knuth_btree">\[2\]<td>
  2565   2610        Donald E. Knuth, <u>The Art Of Computer Programming, Volume 3:
  2566   2611        "Sorting And Searching"</u>, pages 473-480. Addison-Wesley
  2567   2612        Publishing Company, Reading, Massachusetts.
  2568         -    <tr><td style="width:5ex" id="capi_sqlitert_requirements">[3]<td>
         2613  +    <tr><td style="width:5ex" id="capi_sqlitert_requirements">\[3\]<td>
  2569   2614         C API Requirements Document.
  2570         -    <tr><td style="width:5ex" id="sql_sqlitert_requirements">[4]<td>
         2615  +    <tr><td style="width:5ex" id="sql_sqlitert_requirements">\[4\]<td>
  2571   2616         SQL Requirements Document.
  2572         -    <tr><td style="width:5ex" id="io_sqlitert_requirements">[5]<td>
         2617  +    <tr><td style="width:5ex" id="io_sqlitert_requirements">\[5]<td>
  2573   2618         File IO Requirements Document.
  2574   2619     </table>
         2620  +
         2621  +}]
         2622  +</tcl>
         2623  +
         2624  +<div id=toc>
         2625  +<tcl>hd_puts $TOC</tcl>
         2626  +</div id=toc>
         2627  +<tcl>hd_puts [FixReferences $body]</tcl>
         2628  +