formatchng.tcl 4.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132
  1. #
  2. # Run this Tcl script to generate the formatchng.html file.
  3. #
  4. set rcsid {$Id: formatchng.tcl,v 1.4 2002/03/11 02:06:14 drh Exp $ }
  5. puts {<html>
  6. <head>
  7. <title>File Format Changes in SQLite</title>
  8. </head>
  9. <body bgcolor=white>
  10. <h1 align=center>
  11. File Format Changes in SQLite
  12. </h1>}
  13. puts "<p align=center>
  14. (This page was last modified on [lrange $rcsid 3 4] UTC)
  15. </p>"
  16. puts {
  17. <p>
  18. From time to time, enhancements or bug fixes require a change to
  19. the underlying file format for SQLite. When this happens and you
  20. want to upgrade your library, you must convert the contents of your
  21. databases into a portable ASCII representation using the old version
  22. of the library then reload the data using the new version of the
  23. library.
  24. </p>
  25. <p>
  26. You can tell if you should reload your databases by comparing the
  27. version numbers of the old and new libraries. If either of the
  28. first two digits in the version number change, then a reload is
  29. either required or recommended. For example, upgrading from
  30. version 1.0.32 to 2.0.0 requires a reload. So does going from
  31. version 2.0.8 to 2.1.0.
  32. </p>
  33. <p>
  34. The following table summarizes the SQLite file format changes that have
  35. occurred since version 1.0.0:
  36. </p>
  37. <blockquote>
  38. <table border=2 cellpadding=5>
  39. <tr>
  40. <th>Version Change</th>
  41. <th>Approx. Date</th>
  42. <th>Description Of File Format Change</th>
  43. </tr>
  44. <tr>
  45. <td valign="top">1.0.32 to 2.0.0</td>
  46. <td valign="top">2001-Sep-20</td>
  47. <td>Version 1.0.X of SQLite used the GDBM library as its backend
  48. interface to the disk. Beginning in version 2.0.0, GDBM was replaced
  49. by a custom B-Tree library written especially for SQLite. The new
  50. B-Tree backend is twice as fast as GDBM, supports atomic commits and
  51. rollback, and stores an entire database in a single disk file instead
  52. using a separate file for each table as GDBM does. The two
  53. file formats are not even remotely similar.</td>
  54. </tr>
  55. <tr>
  56. <td valign="top">2.0.8 to 2.1.0</td>
  57. <td valign="top">2001-Nov-12</td>
  58. <td>The same basic B-Tree format is used but the details of the
  59. index keys were changed in order to provide better query
  60. optimization opportunities. Some of the headers were also changed in order
  61. to increase the maximum size of a row from 64KB to 24MB.</td>
  62. </tr>
  63. <tr>
  64. <td valign="top">2.1.7 to 2.2.0</td>
  65. <td valign="top">2001-Dec-21</td>
  66. <td>Beginning with version 2.2.0, SQLite no longer builds an index for
  67. an INTEGER PRIMARY KEY column. Instead, it uses that column as the actual
  68. B-Tree key for the main table.<p>Version 2.2.0 and later of the library
  69. will automatically detect when it is reading a 2.1.x database and will
  70. disable the new INTEGER PRIMARY KEY feature. In other words, version
  71. 2.2.x is backwards compatible to version 2.1.x. But version 2.1.x is not
  72. forward compatible with version 2.2.x. If you try to open
  73. a 2.2.x database with an older 2.1.x library and that database contains
  74. an INTEGER PRIMARY KEY, you will likely get a coredump. If the database
  75. schema does not contain any INTEGER PRIMARY KEYs, then the version 2.1.x
  76. and version 2.2.x database files will be identical and completely
  77. interchangeable.</p>
  78. </tr>
  79. <tr>
  80. <td valign="top">2.2.5 to 2.3.0</td>
  81. <td valign="top">2002-Jan-30</td>
  82. <td>Beginning with version 2.3.0, SQLite supports some additional syntax
  83. (the "ON CONFLICT" clause) in the CREATE TABLE and CREATE INDEX statements
  84. that are stored in the SQLITE_MASTER table. If you create a database that
  85. contains this new syntax, then try to read that database using version 2.2.5
  86. or earlier, the parser will not understand the new syntax and you will get
  87. an error. Otherwise, databases for 2.2.x and 2.3.x are interchangeable.</td>
  88. </tr>
  89. <tr>
  90. <td valign="top">2.3.3 to 2.4.0</td>
  91. <td valign="top">2002-Mar-10</td>
  92. <td>Beginning with version 2.4.0, SQLite added support for views.
  93. Information about views is stored in the SQLITE_MASTER table. If an older
  94. version of SQLite attempts to read a database that contains VIEW information
  95. in the SQLITE_MASTER table, the parser will not understand the new syntax
  96. and you will get an error. Also, the
  97. way SQLite keeps track of unused disk blocks in the database file
  98. changed slightly.
  99. If an older version of SQLite attempts to write a database that
  100. was previously written by version 2.4.0 or later, then it may leak disk
  101. blocks.</td>
  102. </tr>
  103. </table>
  104. </blockquote>
  105. <p>
  106. To perform a database reload, have ready versions of the
  107. <b>sqlite</b> command-line utility for both the old and new
  108. version of SQLite. Call these two executables "<b>sqlite-old</b>"
  109. and "<b>sqlite-new</b>". Suppose the name of your old database
  110. is "<b>old.db</b>" and you want to create a new database with
  111. the same information named "<b>new.db</b>". The command to do
  112. this is as follows:
  113. </p>
  114. <blockquote>
  115. echo .dump | sqlite-old old.db | sqlite-new new.db
  116. </blockquote>
  117. }
  118. puts {
  119. <p><hr /></p>
  120. <p><a href="index.html"><img src="/goback.jpg" border=0 />
  121. Back to the SQLite Home Page</a>
  122. </p>
  123. </body></html>}