Index: images/faster-read-blobapi.jpg ================================================================== --- images/faster-read-blobapi.jpg +++ images/faster-read-blobapi.jpg cannot compute difference between binary files Index: images/faster-read-mmap.jpg ================================================================== --- images/faster-read-mmap.jpg +++ images/faster-read-mmap.jpg cannot compute difference between binary files Index: images/faster-read-sql.jpg ================================================================== --- images/faster-read-sql.jpg +++ images/faster-read-sql.jpg cannot compute difference between binary files Index: images/faster-write-safe.jpg ================================================================== --- images/faster-write-safe.jpg +++ images/faster-write-safe.jpg cannot compute difference between binary files Index: images/faster-write-unsafe.jpg ================================================================== --- images/faster-write-unsafe.jpg +++ images/faster-write-unsafe.jpg cannot compute difference between binary files ADDED misc/kvtest-timings.ods Index: misc/kvtest-timings.ods ================================================================== --- /dev/null +++ misc/kvtest-timings.ods cannot compute difference between binary files Index: pages/atomiccommit.in ================================================================== --- pages/atomiccommit.in +++ pages/atomiccommit.in @@ -65,11 +65,11 @@ interface layer that interrogates the underlying filesystem to find the true sector size. As currently implemented (version 3.5.0) this method still returns a hard-coded value of 512 bytes, since there is no standard way of discovering the true sector size on either Unix or Windows. But the method is available for embedded device - manufactures to tweak according to their own needs. And we have + manufacturers to tweak according to their own needs. And we have left open the possibility of filling in a more meaningful implementation on Unix and Windows in the future.
SQLite has traditionally assumed that a sector write is not atomic. However, SQLite does always assume that a sector write is linear. By "linear" Index: pages/capi3ref.in ================================================================== --- pages/capi3ref.in +++ pages/capi3ref.in @@ -232,11 +232,11 @@
These pages are intended to be precise and detailed specification. For a tutorial introduction, see instead:
Hashes: +
Here is a summary of what the core interfaces do: @@ -223,11 +223,11 @@ files or to create and open new database files. While many applications use only a single [database connection], there is no reason why an application cannot call [sqlite3_open()] multiple times in order to open multiple [database connections] - either to the same database or to different databases. Sometimes a multi-threaded application - will create separate [database connections] for each threads. + will create separate [database connections] for each thread. Note that a single [database connection] can access two or more databases using the [ATTACH] SQL command, so it is not necessary to have a separate database connection for each database file.
Index: pages/csv.in ================================================================== --- pages/csv.in +++ pages/csv.in @@ -18,11 +18,11 @@ implementing other virtual tables.-The CVS virtual table is not built into the SQLite amalgamation. +The CSV virtual table is not built into the SQLite amalgamation. It is available as a [https://www.sqlite.org/src/artifact?ci=trunk&filename=ext/misc/csv.c|separate source file] that can be compiled into a [loadable extension]. Typical usage of the CSV virtual table from the [command-line shell] would be something like this: @@ -81,14 +81,14 @@
The data= argument specifies that TEXT is the literal content of the CSV file.
schema=SCHEMA
The schema= argument specifies a [CREATE TABLE] statement that -the CVS virtual table passes to the [sqlite3_declare_vtab()] interface in +the CSV virtual table passes to the [sqlite3_declare_vtab()] interface in order to define the number and names of the columns in the virtual table. If both the schema= and the columns= arguments are omitted, -then the CVS virtual table reads the first row of the input content in order +then the CSV virtual table reads the first row of the input content in order to determine the number of columns and names the columns cNNN where NNN values are consecutive integers. It is not allowed to have both schema= and columns= arguments.
columns=N Index: pages/download.in ================================================================== --- pages/download.in +++ pages/download.in @@ -425,23 +425,23 @@ The [amalgamation] source code files (the "sqlite3.c" and "sqlite3.h" files) build products and are not contained in raw source code tree.
-http://www.sqlite.org/cgi/src (Dallas)
-http://www2.sqlite.org/cgi/src (Newark)
-http://www3.sqlite.org/cgi/src (Fremont)
+https://www.sqlite.org/cgi/src (Dallas)
+https://www2.sqlite.org/cgi/src (Newark)
+https://www3.sqlite.org/cgi/src (San Francisco)
The documentation is maintained in separate [http://www.fossil-scm.org/ | Fossil] repositories located at:
-http://www.sqlite.org/cgi/docsrc (Dallas)
-http://www2.sqlite.org/cgi/docsrc (Newark)
-http://www3.sqlite.org/cgi/docsrc (Fremont)
+https://www.sqlite.org/cgi/docsrc (Dallas)
+https://www2.sqlite.org/cgi/docsrc (Newark)
+https://www3.sqlite.org/cgi/docsrc (San Francisco)