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>

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.

    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

    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

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>

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>

        /// 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>

        /// 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>

        /// This value represents the GLOB operator.
        /// </summary>
        Glob = 66,

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

























    }
    #endregion

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

    #region SQLiteIndexFlags Enumeration
    /// <summary>

        /// 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>