System.Data.SQLite
Check-in [87a4f65f05]
Not logged in

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

Overview
Comment:Pickup and integrate the SQLite core library 3.21.0 docs from upstream.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 87a4f65f0573ea5d61b21199964415110bcb444d
User & Date: mistachkin 2017-10-27 03:36:54
Context
2017-10-31
22:21
Improvements to the doc comments for the BackupDatabase method. check-in: e4df0a7df0 user: mistachkin tags: trunk
2017-10-27
03:36
Pickup and integrate the SQLite core library 3.21.0 docs from upstream. check-in: 87a4f65f05 user: mistachkin tags: trunk
03:30
Update SQLite core library to the 3.21.0 release. check-in: 24e3dd0f10 user: mistachkin tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to Doc/Extra/Core/lang_detach.html.

103
104
105
106
107
108
109
110
111
112
113
When not in <a href="sharedcache.html">shared cache mode</a>, 
it is possible to have the same database file attached multiple times using 
different names, and detaching one connection to a file will leave the 
others intact.</p>
In <a href="sharedcache.html">shared cache mode</a>, attempting to attach the same database file more
than once results in an error.

<p>This statement will fail if SQLite is in the middle of a transaction.</p>










<


<
103
104
105
106
107
108
109

110
111

When not in <a href="sharedcache.html">shared cache mode</a>, 
it is possible to have the same database file attached multiple times using 
different names, and detaching one connection to a file will leave the 
others intact.</p>
In <a href="sharedcache.html">shared cache mode</a>, attempting to attach the same database file more
than once results in an error.





Changes to Doc/Extra/Core/pragma.html.

117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
...
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
    SQL statements.  Whether or not the pragma runs during sqlite3_prepare()
    or sqlite3_step() depends on the pragma and on the specific release
    of SQLite.
<li>The pragma command is specific to SQLite and is
    not compatible with any other SQL database engine.
</ul>

<p>The C-language API for SQLite provides the <a href="c3ref/c_fcntl_busyhandler.html#sqlitefcntlpragma">SQLITE_FCNTL_PRAGMA</a>
<a href="c3ref/file_control.html">file control</a> which gives <a href="vfs.html">VFS</a> implementations the
opportunity to add new PRAGMA statements or to override the meaning of
built-in PRAGMA statements.</p>


<hr /><a name="syntax"></a>
<h2>PRAGMA command syntax</h2>
................................................................................
</pre></blockquote>

<p>
Additional notes:
<ul>
<li><p>
Table-valued functions exist only for built-in PRAGMAs, not for PRAGMAs
defined using the <a href="c3ref/c_fcntl_busyhandler.html#sqlitefcntlpragma">SQLITE_FCNTL_PRAGMA</a> file control.
<li><p>
Table-valued functions exist only for PRAGMAs that return results and
that have no side-effects.
<li><p>
This feature could be used to implement
<a href="https://en.wikipedia.org/wiki/Information_schema">information schema</a>
by first creating a separate schema using







|







 







|







117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
...
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
    SQL statements.  Whether or not the pragma runs during sqlite3_prepare()
    or sqlite3_step() depends on the pragma and on the specific release
    of SQLite.
<li>The pragma command is specific to SQLite and is
    not compatible with any other SQL database engine.
</ul>

<p>The C-language API for SQLite provides the <a href="c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlpragma">SQLITE_FCNTL_PRAGMA</a>
<a href="c3ref/file_control.html">file control</a> which gives <a href="vfs.html">VFS</a> implementations the
opportunity to add new PRAGMA statements or to override the meaning of
built-in PRAGMA statements.</p>


<hr /><a name="syntax"></a>
<h2>PRAGMA command syntax</h2>
................................................................................
</pre></blockquote>

<p>
Additional notes:
<ul>
<li><p>
Table-valued functions exist only for built-in PRAGMAs, not for PRAGMAs
defined using the <a href="c3ref/c_fcntl_begin_atomic_write.html#sqlitefcntlpragma">SQLITE_FCNTL_PRAGMA</a> file control.
<li><p>
Table-valued functions exist only for PRAGMAs that return results and
that have no side-effects.
<li><p>
This feature could be used to implement
<a href="https://en.wikipedia.org/wiki/Information_schema">information schema</a>
by first creating a separate schema using

Changes to Doc/Special/Core/vtab.html.

569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
...
675
676
677
678
679
680
681
682
683
684
685
686






687
688
689
690
691
692
693
...
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813





814
815
816
817
818
819
820
821
....
1239
1240
1241
1242
1243
1244
1245
1246

1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261


1262
1263

1264
1265
1266


1267
1268

1269
1270
1271
1272
1273

1274
1275
1276
1277
1278
1279
1280
been reported up to the application.

</p><p>
If the xCreate method is omitted (left as a NULL pointer) then the
virtual table is an <a href="vtab.html#epoonlyvtab">eponymous-only virtual table</a>.  New instances of
the virtual table cannot be created using <a href="lang_createvtab.html">CREATE VIRTUAL TABLE</a> and the
virtual table can only be used via its module name.
Note that SQLite versions prior to 3.9.0 do not understand
eponymous-only virtual tables and will segfault if an attempt is made
to <a href="lang_createvtab.html">CREATE VIRTUAL TABLE</a> on an eponymous-only virtual table because
the xCreate method was not checked for null.

</p><p>
If the xCreate method is the exact same pointer as the <a href="vtab.html#xconnect">xConnect</a> method,
that indicates that the virtual table does not need to initialize backing
................................................................................
virtual table.  Enforcement is the responsibility of the underlying
virtual table implementation.  But SQLite does assume that the PRIMARY KEY
constraint is valid - that the identified columns really are UNIQUE and
NOT NULL - and it uses that assumption to optimize queries against the
virtual table.

</p><p>The rowid column is not accessible on a
WITHOUT ROWID virtual table (of course).  Furthermore, since the
<a href="vtab.html#xupdate">xUpdate</a> method depends on having a valid rowid, the <a href="vtab.html#xupdate">xUpdate</a> method 
must be NULL for a WITHOUT ROWID virtual table.  That in turn means that
WITHOUT ROWID virtual tables must be read-only.








<a name="xconnect"></a>

</p><h2 id="the_xconnect_method"><span>2.2. </span>The xConnect Method</h2>

<div class="codeblock"><pre>int (*xConnect)(sqlite3*, void *pAux,
             int argc, char **argv,
................................................................................
version - perhaps comparing the value returned from <a href="c3ref/libversion.html">sqlite3_libversion_number()</a>
against constants 3008002, 3009000, and/or 3010000. The result of attempting 
to access these fields in an sqlite3_index_info structure created by an 
older version of SQLite are undefined.

</p><p>In addition, there are some defined constants:

</p><div class="codeblock"><pre>#define SQLITE_INDEX_CONSTRAINT_EQ      2
#define SQLITE_INDEX_CONSTRAINT_GT      4
#define SQLITE_INDEX_CONSTRAINT_LE      8
#define SQLITE_INDEX_CONSTRAINT_LT     16
#define SQLITE_INDEX_CONSTRAINT_GE     32
#define SQLITE_INDEX_CONSTRAINT_MATCH  64
#define SQLITE_INDEX_CONSTRAINT_LIKE   65     /* 3.10.0 and later only */
#define SQLITE_INDEX_CONSTRAINT_GLOB   66     /* 3.10.0 and later only */
#define SQLITE_INDEX_CONSTRAINT_REGEXP 67     /* 3.10.0 and later only */





#define SQLITE_INDEX_SCAN_UNIQUE        1     /* Scan visits at most 1 row */
</pre></div>

<p>The SQLite core calls the xBestIndex method when it is compiling a query
that involves a virtual table. In other words, SQLite calls this method 
when it is running <a href="c3ref/prepare.html">sqlite3_prepare()</a> or the equivalent. 
By calling this method, the 
SQLite core is saying to the virtual table that it needs to access 
................................................................................
into the virtual table. If argv[1] is an SQL NULL, then the implementation 
must choose a rowid for the newly inserted row. Subsequent argv[] 
entries contain values of the columns of the virtual table, in the 
order that the columns were declared. The number of columns will
match the table declaration that the <a href="vtab.html#xconnect">xConnect</a> or <a href="vtab.html#xcreate">xCreate</a> method made 
using the <a href="c3ref/declare_vtab.html">sqlite3_declare_vtab()</a> call.  All hidden columns are included.

</p><p>When doing an insert without a rowid (argc>1, argv[1] is an SQL NULL), the 

implementation must set *pRowid to the rowid of the newly inserted row; 
this will become the value returned by the <a href="c3ref/last_insert_rowid.html">sqlite3_last_insert_rowid()</a>
function. Setting this value in all the other cases is a harmless no-op;
the SQLite engine ignores the *pRowid return value if argc==1 or 
argv[1] is not an SQL NULL.

</p><p>Each call to xUpdate will fall into one of cases shown below.
Not that references to <b>argv&#91;i&#93</b> mean the SQL value
held within the argv&#91;i&#93; object, not the argv&#91;i&#93;
object itself.

</p><blockquote>
<dl>
<dt><b>argc = 1</b>
</dt><dd><p>The single row with rowid equal to argv[0] is deleted. No insert occurs.



</p></dd><dt><b>argc &gt; 1 <br> argv[0] = NULL</b>

</dt><dd><p>A new row is inserted with a rowid argv[1] and column values in
       argv[2] and following.  If argv[1] is an SQL NULL,
       the a new unique rowid is generated automatically.



</p></dd><dt><b>argc &gt; 1 <br> argv[0] &ne; NULL <br> argv[0] = argv[1]</b>

</dt><dd><p>The row with rowid argv[0] is updated with new values 
       in argv[2] and following parameters.

</p></dd><dt><b>argc &gt; 1 <br> argv[0] &ne; NULL <br> argv[0] &ne; argv[1]</b>
</dt><dd><p> The row with rowid argv[0] is updated with rowid argv[1] 

and new values in argv[2] and following parameters. This will occur 
when an SQL statement updates a rowid, as in the statement:
</p><blockquote>
   <a href="lang_update.html">UPDATE</a> table SET rowid=rowid+1 WHERE ...; 
</blockquote>
</dd></dl>
</blockquote>







|







 







|
<
<
<

>
>
>
>
>
>







 







|
|
|
|
|
|
|
|
|
>
>
>
>
>
|







 







|
>
|












|
|
>
>


>
|
|
|
>
>


>
|
|


|
>







569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
...
675
676
677
678
679
680
681
682



683
684
685
686
687
688
689
690
691
692
693
694
695
696
...
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
....
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
been reported up to the application.

</p><p>
If the xCreate method is omitted (left as a NULL pointer) then the
virtual table is an <a href="vtab.html#epoonlyvtab">eponymous-only virtual table</a>.  New instances of
the virtual table cannot be created using <a href="lang_createvtab.html">CREATE VIRTUAL TABLE</a> and the
virtual table can only be used via its module name.
Note that SQLite versions prior to 3.9.0 (2015-10-14) do not understand
eponymous-only virtual tables and will segfault if an attempt is made
to <a href="lang_createvtab.html">CREATE VIRTUAL TABLE</a> on an eponymous-only virtual table because
the xCreate method was not checked for null.

</p><p>
If the xCreate method is the exact same pointer as the <a href="vtab.html#xconnect">xConnect</a> method,
that indicates that the virtual table does not need to initialize backing
................................................................................
virtual table.  Enforcement is the responsibility of the underlying
virtual table implementation.  But SQLite does assume that the PRIMARY KEY
constraint is valid - that the identified columns really are UNIQUE and
NOT NULL - and it uses that assumption to optimize queries against the
virtual table.

</p><p>The rowid column is not accessible on a
WITHOUT ROWID virtual table (of course).




</p><p>The <a href="vtab.html#xupdate">xUpdate</a> method was originally designed around having a
<a href="lang_createtable.html#rowid">ROWID</a> as a single value.  The <a href="vtab.html#xupdate">xUpdate</a> method has been expanded to
accommodate an arbitrary PRIMARY KEY in place of the ROWID, but the
PRIMARY KEY must still be only one column.  For this reason, SQLite
will reject any WITHOUT ROWID virtual table that has more than one
PRIMARY KEY column and a non-NULL xUpdate method.

<a name="xconnect"></a>

</p><h2 id="the_xconnect_method"><span>2.2. </span>The xConnect Method</h2>

<div class="codeblock"><pre>int (*xConnect)(sqlite3*, void *pAux,
             int argc, char **argv,
................................................................................
version - perhaps comparing the value returned from <a href="c3ref/libversion.html">sqlite3_libversion_number()</a>
against constants 3008002, 3009000, and/or 3010000. The result of attempting 
to access these fields in an sqlite3_index_info structure created by an 
older version of SQLite are undefined.

</p><p>In addition, there are some defined constants:

</p><div class="codeblock"><pre>#define SQLITE_INDEX_CONSTRAINT_EQ         2
#define SQLITE_INDEX_CONSTRAINT_GT         4
#define SQLITE_INDEX_CONSTRAINT_LE         8
#define SQLITE_INDEX_CONSTRAINT_LT        16
#define SQLITE_INDEX_CONSTRAINT_GE        32
#define SQLITE_INDEX_CONSTRAINT_MATCH     64
#define SQLITE_INDEX_CONSTRAINT_LIKE      65  /* 3.10.0 and later */
#define SQLITE_INDEX_CONSTRAINT_GLOB      66  /* 3.10.0 and later */
#define SQLITE_INDEX_CONSTRAINT_REGEXP    67  /* 3.10.0 and later */
#define SQLITE_INDEX_CONSTRAINT_NE        68  /* 3.21.0 and later */
#define SQLITE_INDEX_CONSTRAINT_ISNOT     69  /* 3.21.0 and later */
#define SQLITE_INDEX_CONSTRAINT_ISNOTNULL 70  /* 3.21.0 and later */
#define SQLITE_INDEX_CONSTRAINT_ISNULL    71  /* 3.21.0 and later */
#define SQLITE_INDEX_CONSTRAINT_IS        72  /* 3.21.0 and later */
#define SQLITE_INDEX_SCAN_UNIQUE           1  /* Scan visits at most 1 row */
</pre></div>

<p>The SQLite core calls the xBestIndex method when it is compiling a query
that involves a virtual table. In other words, SQLite calls this method 
when it is running <a href="c3ref/prepare.html">sqlite3_prepare()</a> or the equivalent. 
By calling this method, the 
SQLite core is saying to the virtual table that it needs to access 
................................................................................
into the virtual table. If argv[1] is an SQL NULL, then the implementation 
must choose a rowid for the newly inserted row. Subsequent argv[] 
entries contain values of the columns of the virtual table, in the 
order that the columns were declared. The number of columns will
match the table declaration that the <a href="vtab.html#xconnect">xConnect</a> or <a href="vtab.html#xcreate">xCreate</a> method made 
using the <a href="c3ref/declare_vtab.html">sqlite3_declare_vtab()</a> call.  All hidden columns are included.

</p><p>When doing an insert without a rowid (argc>1, argv[1] is an SQL NULL),
on a virtual table that uses ROWID (but not on a <a href="vtab.html#worid">WITHOUT ROWID virtual table</a>,
the implementation must set *pRowid to the rowid of the newly inserted row; 
this will become the value returned by the <a href="c3ref/last_insert_rowid.html">sqlite3_last_insert_rowid()</a>
function. Setting this value in all the other cases is a harmless no-op;
the SQLite engine ignores the *pRowid return value if argc==1 or 
argv[1] is not an SQL NULL.

</p><p>Each call to xUpdate will fall into one of cases shown below.
Not that references to <b>argv&#91;i&#93</b> mean the SQL value
held within the argv&#91;i&#93; object, not the argv&#91;i&#93;
object itself.

</p><blockquote>
<dl>
<dt><b>argc = 1 <br> argv[0] &ne; NULL</b>
</dt><dd><p>
The single row with rowid or PRIMARY KEY equal to argv[0] is deleted. 
No insert occurs.

</p></dd><dt><b>argc &gt; 1 <br> argv[0] = NULL</b>
</dt><dd><p>
A new row is inserted with column values taken from
argv[2] and following.  In a rowid virtual table, if argv[1] is an SQL NULL,
then a new unique rowid is generated automatically.  The argv[1] will be NULL
for a <a href="vtab.html#worid">WITHOUT ROWID virtual table</a>, in which case the implementation should
take the PRIMARY KEY value from the appropiate column in argv[2] and following.

</p></dd><dt><b>argc &gt; 1 <br> argv[0] &ne; NULL <br> argv[0] = argv[1]</b>
</dt><dd><p>
The row with rowid or PRIMARY KEY argv[0] is updated with new values 
in argv[2] and following parameters.

</p></dd><dt><b>argc &gt; 1 <br> argv[0] &ne; NULL <br> argv[0] &ne; argv[1]</b>
</dt><dd><p> The row with rowid or PRIMARY KEY argv[0] is updated with 
the rowid or PRIMARY KEY in argv[1] 
and new values in argv[2] and following parameters. This will occur 
when an SQL statement updates a rowid, as in the statement:
</p><blockquote>
   <a href="lang_update.html">UPDATE</a> table SET rowid=rowid+1 WHERE ...; 
</blockquote>
</dd></dl>
</blockquote>

Changes to System.Data.SQLite/ISQLiteNativeModule.cs.

92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
...
199
200
201
202
203
204
205
206
207
208




209

210
211
212
213
214
215
216
...
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419





420
421
422
423
424
425
426
427
....
1042
1043
1044
1045
1046
1047
1048
1049

1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065


1066
1067

1068
1069


1070
1071

1072
1073
1074

1075
1076
1077
1078
1079
1080
1081
        /// been reported up to the application.
        /// </para>
        /// <para>
        /// If the xCreate method is omitted (left as a NULL pointer) then the
        /// virtual table is an eponymous-only virtual table.  New instances of
        /// the virtual table cannot be created using CREATE VIRTUAL TABLE and the
        /// virtual table can only be used via its module name.
        /// Note that SQLite versions prior to 3.9.0 do not understand
        /// eponymous-only virtual tables and will segfault if an attempt is made
        /// to CREATE VIRTUAL TABLE on an eponymous-only virtual table because
        /// the xCreate method was not checked for null.
        /// </para>
        /// <para>
        /// If the xCreate method is the exact same pointer as the xConnect method,
        /// that indicates that the virtual table does not need to initialize backing
................................................................................
        /// virtual table implementation.  But SQLite does assume that the PRIMARY KEY
        /// constraint is valid - that the identified columns really are UNIQUE and
        /// NOT NULL - and it uses that assumption to optimize queries against the
        /// virtual table.
        /// </para>
        /// <para>
        /// The rowid column is not accessible on a
        /// WITHOUT ROWID virtual table (of course).  Furthermore, since the
        /// xUpdate method depends on having a valid rowid, the xUpdate method 
        /// must be NULL for a WITHOUT ROWID virtual table.  That in turn means that




        /// WITHOUT ROWID virtual tables must be read-only.

        /// </para>
        /// </summary>
        /// <param name="pDb">
        /// The native database connection handle.
        /// </param>
        /// <param name="pAux">
        /// The original native pointer value that was provided to the
................................................................................
        /// to access these fields in an sqlite3_index_info structure created by an 
        /// older version of SQLite are undefined.
        /// </para>
        /// <para>
        /// In addition, there are some defined constants:
        /// </para>
        /// <para><code>
        /// #define SQLITE_INDEX_CONSTRAINT_EQ      2
        /// #define SQLITE_INDEX_CONSTRAINT_GT      4
        /// #define SQLITE_INDEX_CONSTRAINT_LE      8
        /// #define SQLITE_INDEX_CONSTRAINT_LT     16
        /// #define SQLITE_INDEX_CONSTRAINT_GE     32
        /// #define SQLITE_INDEX_CONSTRAINT_MATCH  64
        /// #define SQLITE_INDEX_CONSTRAINT_LIKE   65     /* 3.10.0 and later only */
        /// #define SQLITE_INDEX_CONSTRAINT_GLOB   66     /* 3.10.0 and later only */
        /// #define SQLITE_INDEX_CONSTRAINT_REGEXP 67     /* 3.10.0 and later only */





        /// #define SQLITE_INDEX_SCAN_UNIQUE        1     /* Scan visits at most 1 row */
        /// </code></para>
        /// <para>
        /// The SQLite core calls the xBestIndex method when it is compiling a query
        /// that involves a virtual table. In other words, SQLite calls this method 
        /// when it is running sqlite3_prepare() or the equivalent. 
        /// By calling this method, the 
        /// SQLite core is saying to the virtual table that it needs to access 
................................................................................
        /// must choose a rowid for the newly inserted row. Subsequent argv[] 
        /// entries contain values of the columns of the virtual table, in the 
        /// order that the columns were declared. The number of columns will
        /// match the table declaration that the xConnect or xCreate method made 
        /// using the sqlite3_declare_vtab() call.  All hidden columns are included.
        /// </para>
        /// <para>
        /// When doing an insert without a rowid (argc>1, argv[1] is an SQL NULL), the 

        /// implementation must set *pRowid to the rowid of the newly inserted row; 
        /// this will become the value returned by the sqlite3_last_insert_rowid()
        /// function. Setting this value in all the other cases is a harmless no-op;
        /// the SQLite engine ignores the *pRowid return value if argc==1 or 
        /// argv[1] is not an SQL NULL.
        /// </para>
        /// <para>
        /// Each call to xUpdate will fall into one of cases shown below.
        /// Not that references to <![CDATA[<b>]]>argv[i]<![CDATA[</b>]]> mean the SQL value
        /// held within the argv[i] object, not the argv[i]
        /// object itself.
        /// </para>
        /// <para><code>
        /// <![CDATA[<dl>]]>
        /// <![CDATA[<dt>]]><![CDATA[<b>]]>argc = 1<![CDATA[</b>]]>
        /// <![CDATA[</dt>]]><![CDATA[<dd>]]>The single row with rowid equal to argv[0] is deleted. No insert occurs.


        /// <![CDATA[</dd>]]><![CDATA[<dt>]]><![CDATA[<b>]]>argc &gt; 1 <![CDATA[<br>]]> argv[0] = NULL<![CDATA[</b>]]>
        /// <![CDATA[</dt>]]><![CDATA[<dd>]]>A new row is inserted with a rowid argv[1] and column values in

        ///        argv[2] and following.  If argv[1] is an SQL NULL,
        ///        the a new unique rowid is generated automatically.


        /// <![CDATA[</dd>]]><![CDATA[<dt>]]><![CDATA[<b>]]>argc &gt; 1 <![CDATA[<br>]]> argv[0] &#8800; NULL <![CDATA[<br>]]> argv[0] = argv[1]<![CDATA[</b>]]>
        /// <![CDATA[</dt>]]><![CDATA[<dd>]]>The row with rowid argv[0] is updated with new values 

        ///        in argv[2] and following parameters.
        /// <![CDATA[</dd>]]><![CDATA[<dt>]]><![CDATA[<b>]]>argc &gt; 1 <![CDATA[<br>]]> argv[0] &#8800; NULL <![CDATA[<br>]]> argv[0] &#8800; argv[1]<![CDATA[</b>]]>
        /// <![CDATA[</dt>]]><![CDATA[<dd>]]> The row with rowid argv[0] is updated with rowid argv[1] 

        /// and new values in argv[2] and following parameters. This will occur 
        /// when an SQL statement updates a rowid, as in the statement:
        /// <para><code>
        ///    UPDATE table SET rowid=rowid+1 WHERE ...; 
        /// </code></para>
        /// <![CDATA[</dd>]]><![CDATA[</dl>]]>
        /// </code></para>







|







 







|
|
|
>
>
>
>
|
>







 







|
|
|
|
|
|
|
|
|
>
>
>
>
>
|







 







|
>
|













|
|
>
>

|
>
|
|
>
>

|
>
|

|
>







92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
...
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
...
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
....
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
        /// been reported up to the application.
        /// </para>
        /// <para>
        /// If the xCreate method is omitted (left as a NULL pointer) then the
        /// virtual table is an eponymous-only virtual table.  New instances of
        /// the virtual table cannot be created using CREATE VIRTUAL TABLE and the
        /// virtual table can only be used via its module name.
        /// Note that SQLite versions prior to 3.9.0 (2015-10-14) do not understand
        /// eponymous-only virtual tables and will segfault if an attempt is made
        /// to CREATE VIRTUAL TABLE on an eponymous-only virtual table because
        /// the xCreate method was not checked for null.
        /// </para>
        /// <para>
        /// If the xCreate method is the exact same pointer as the xConnect method,
        /// that indicates that the virtual table does not need to initialize backing
................................................................................
        /// virtual table implementation.  But SQLite does assume that the PRIMARY KEY
        /// constraint is valid - that the identified columns really are UNIQUE and
        /// NOT NULL - and it uses that assumption to optimize queries against the
        /// virtual table.
        /// </para>
        /// <para>
        /// The rowid column is not accessible on a
        /// WITHOUT ROWID virtual table (of course).
        /// </para>
        /// <para>
        /// The xUpdate method was originally designed around having a
        /// ROWID as a single value.  The xUpdate method has been expanded to
        /// accommodate an arbitrary PRIMARY KEY in place of the ROWID, but the
        /// PRIMARY KEY must still be only one column.  For this reason, SQLite
        /// will reject any WITHOUT ROWID virtual table that has more than one
        /// PRIMARY KEY column and a non-NULL xUpdate method.
        /// </para>
        /// </summary>
        /// <param name="pDb">
        /// The native database connection handle.
        /// </param>
        /// <param name="pAux">
        /// The original native pointer value that was provided to the
................................................................................
        /// to access these fields in an sqlite3_index_info structure created by an 
        /// older version of SQLite are undefined.
        /// </para>
        /// <para>
        /// In addition, there are some defined constants:
        /// </para>
        /// <para><code>
        /// #define SQLITE_INDEX_CONSTRAINT_EQ         2
        /// #define SQLITE_INDEX_CONSTRAINT_GT         4
        /// #define SQLITE_INDEX_CONSTRAINT_LE         8
        /// #define SQLITE_INDEX_CONSTRAINT_LT        16
        /// #define SQLITE_INDEX_CONSTRAINT_GE        32
        /// #define SQLITE_INDEX_CONSTRAINT_MATCH     64
        /// #define SQLITE_INDEX_CONSTRAINT_LIKE      65  /* 3.10.0 and later */
        /// #define SQLITE_INDEX_CONSTRAINT_GLOB      66  /* 3.10.0 and later */
        /// #define SQLITE_INDEX_CONSTRAINT_REGEXP    67  /* 3.10.0 and later */
        /// #define SQLITE_INDEX_CONSTRAINT_NE        68  /* 3.21.0 and later */
        /// #define SQLITE_INDEX_CONSTRAINT_ISNOT     69  /* 3.21.0 and later */
        /// #define SQLITE_INDEX_CONSTRAINT_ISNOTNULL 70  /* 3.21.0 and later */
        /// #define SQLITE_INDEX_CONSTRAINT_ISNULL    71  /* 3.21.0 and later */
        /// #define SQLITE_INDEX_CONSTRAINT_IS        72  /* 3.21.0 and later */
        /// #define SQLITE_INDEX_SCAN_UNIQUE           1  /* Scan visits at most 1 row */
        /// </code></para>
        /// <para>
        /// The SQLite core calls the xBestIndex method when it is compiling a query
        /// that involves a virtual table. In other words, SQLite calls this method 
        /// when it is running sqlite3_prepare() or the equivalent. 
        /// By calling this method, the 
        /// SQLite core is saying to the virtual table that it needs to access 
................................................................................
        /// must choose a rowid for the newly inserted row. Subsequent argv[] 
        /// entries contain values of the columns of the virtual table, in the 
        /// order that the columns were declared. The number of columns will
        /// match the table declaration that the xConnect or xCreate method made 
        /// using the sqlite3_declare_vtab() call.  All hidden columns are included.
        /// </para>
        /// <para>
        /// When doing an insert without a rowid (argc>1, argv[1] is an SQL NULL),
        /// on a virtual table that uses ROWID (but not on a WITHOUT ROWID virtual table,
        /// the implementation must set *pRowid to the rowid of the newly inserted row; 
        /// this will become the value returned by the sqlite3_last_insert_rowid()
        /// function. Setting this value in all the other cases is a harmless no-op;
        /// the SQLite engine ignores the *pRowid return value if argc==1 or 
        /// argv[1] is not an SQL NULL.
        /// </para>
        /// <para>
        /// Each call to xUpdate will fall into one of cases shown below.
        /// Not that references to <![CDATA[<b>]]>argv[i]<![CDATA[</b>]]> mean the SQL value
        /// held within the argv[i] object, not the argv[i]
        /// object itself.
        /// </para>
        /// <para><code>
        /// <![CDATA[<dl>]]>
        /// <![CDATA[<dt>]]><![CDATA[<b>]]>argc = 1 <![CDATA[<br>]]> argv[0] &#8800; NULL<![CDATA[</b>]]>
        /// <![CDATA[</dt>]]><![CDATA[<dd>]]>
        /// The single row with rowid or PRIMARY KEY equal to argv[0] is deleted. 
        /// No insert occurs.
        /// <![CDATA[</dd>]]><![CDATA[<dt>]]><![CDATA[<b>]]>argc &gt; 1 <![CDATA[<br>]]> argv[0] = NULL<![CDATA[</b>]]>
        /// <![CDATA[</dt>]]><![CDATA[<dd>]]>
        /// A new row is inserted with column values taken from
        /// argv[2] and following.  In a rowid virtual table, if argv[1] is an SQL NULL,
        /// then a new unique rowid is generated automatically.  The argv[1] will be NULL
        /// for a WITHOUT ROWID virtual table, in which case the implementation should
        /// take the PRIMARY KEY value from the appropiate column in argv[2] and following.
        /// <![CDATA[</dd>]]><![CDATA[<dt>]]><![CDATA[<b>]]>argc &gt; 1 <![CDATA[<br>]]> argv[0] &#8800; NULL <![CDATA[<br>]]> argv[0] = argv[1]<![CDATA[</b>]]>
        /// <![CDATA[</dt>]]><![CDATA[<dd>]]>
        /// The row with rowid or PRIMARY KEY argv[0] is updated with new values 
        /// in argv[2] and following parameters.
        /// <![CDATA[</dd>]]><![CDATA[<dt>]]><![CDATA[<b>]]>argc &gt; 1 <![CDATA[<br>]]> argv[0] &#8800; NULL <![CDATA[<br>]]> argv[0] &#8800; argv[1]<![CDATA[</b>]]>
        /// <![CDATA[</dt>]]><![CDATA[<dd>]]> The row with rowid or PRIMARY KEY argv[0] is updated with 
        /// the rowid or PRIMARY KEY in argv[1] 
        /// and new values in argv[2] and following parameters. This will occur 
        /// when an SQL statement updates a rowid, as in the statement:
        /// <para><code>
        ///    UPDATE table SET rowid=rowid+1 WHERE ...; 
        /// </code></para>
        /// <![CDATA[</dd>]]><![CDATA[</dl>]]>
        /// </code></para>

Changes to System.Data.SQLite/SQLiteModule.cs.

751
752
753
754
755
756
757
758

























759
760
761
762
763
764
765
        /// This value represents the GLOB operator.
        /// </summary>
        Glob = 66,

        /// <summary>
        /// This value represents the REGEXP operator.
        /// </summary>
        Regexp = 67

























    }
    #endregion

    ///////////////////////////////////////////////////////////////////////////

    #region SQLiteIndexFlags Enumeration
    /// <summary>







|
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
        /// This value represents the GLOB operator.
        /// </summary>
        Glob = 66,

        /// <summary>
        /// This value represents the REGEXP operator.
        /// </summary>
        Regexp = 67,

        /// <summary>
        /// This value represents the inequality operator.
        /// </summary>
        NotEqualTo = 68,

        /// <summary>
        /// This value represents the IS NOT operator.
        /// </summary>
        IsNot = 69,

        /// <summary>
        /// This value represents the IS NOT NULL operator.
        /// </summary>
        IsNotNull = 70,

        /// <summary>
        /// This value represents the IS NULL operator.
        /// </summary>
        IsNull = 71,

        /// <summary>
        /// This value represents the IS operator.
        /// </summary>
        Is = 72
    }
    #endregion

    ///////////////////////////////////////////////////////////////////////////

    #region SQLiteIndexFlags Enumeration
    /// <summary>