<a to main page</a>
<br><hr>
<h1>List of topics</h1>
<ul>
<li><a href="#VirtualShape"><b>VirtualShape - Emulation of
<li><a href="#VirtualDBF"><b>VirtualDBF - Emulation of DBF
<li><a href="#VirtualText"><b>VirtualText - Emulation of
<li><a href="#VirtualXL"><b>VirtualXL - Emulation of MS Excel
<li><a href="#VirtualFDO"><b>VirtualFDO - Emulation of FDO binary Geometries
<li><a href="#VirtualGPKG"><b>VirtualGPKG - Emulation of
</ul>
<br><hr>
<h1><a
The <b>VirtualShape</b> Interface allows to directly access an external ShapeFile by using standard Spatial SQL queries.<br>
Syntax for creating a VirtualShape Table:
<verbatim>
SELECT CREATE VIRTUAL TABLE my_table USING VirtualShape ( shp_path , charset_encoding , srid );

SELECT CREATE VIRTUAL TABLE my_table USING VirtualShape ( shp_path , charset_encoding , srid , text_dates );

SELECT CREATE VIRTUAL TABLE my_table USING VirtualShape ( shp_path , charset_encoding , srid , text_dates , colname_case );
</verbatim>
Supported arguments and their interpretation:
<ul>
<li><b>shp_path</b> the relative or absolute pathname leading to the external Shapefile.
<ul>
<li><b>Note</b>: any Shapefile requires at least three individual members sharing the same base name but with different suffixes (<i>*.shp</i>, <i>*.shx</i> and <i>*.dbf</i>).<br>
All suffixes will be automatically handled by VirtualShape, and consequently the <b>shp_path</b> argument <b><u><i>must not specify any just the bare base path must be passed.</li>

<li><b>charset_encoding</b> canonical name of the charset encoding adopted by the <b>DBF</b> member.
<ul>
<li>Examples of valid names are: <b>ASCII</b>, <b>UTF-8</b>, <b>CP850</b>, <b>CP1252</b>,
<li>You can check the full list of supported charset encodings <a

<li><b>srid</b> the SRID value of all Geometries within the Shapefile.
<ul>
<li>Examples of valid SRID values are: <b>4326</b>, <b>3003</b>,

<li><b>text_dates</b> this is a <b>BOOLEAN</b> flag:
<ul>
<li>if set to <b>0</b> (<b>FALSE</b>) all fields of the <b>DATE</b> type will be represented as <a
<li>if set to any other integer value (<b>TRUE</b>) all fields of the <b>DATE</b> type will be represented as Text Strings as e.g.
<li>if not explicitly specified, <b>TRUE</b> will always be assumed (default setting).</li>

<li><b>colname_case</b> this argument specifies if all column names should be considered uppercase or lowercase.<br>
Valid settings are:
<ul>
<li><b>uppercase</b> or <b>upper</b>: all column names will be fully capitalized.</li>
<li><b>lowercase</b> or <b>lower</b>: all column names will be full lowercase.</li>
<li><b>samecase</b> or <b>same</b>: all column names will be exactly preserved as they are defined into the DBF member.</li>
<li>if not specified, or if any other definition definition is found, <b>lowercase</b> will always be assumed (default setting).</li>

</ul><br>
<table bgcolor="#ffffd0" cellpadding="18"><tr><td>
<b>Note</b>: any Text String, quoted or not, when it appears as a Virtual Table argument has the same effect.
<verbatim>
SELECT CREATE VIRTUAL TABLE my_table USING VirtualShape( , CP1252 , 3003 , 1 , lower );
or
SELECT CREATE VIRTUAL TABLE my_table USING VirtualShape( , 'CP1252' , 3003 , 1 , 'lower' );
</verbatim>
Both notations will produce the same result.

<br>
<table bgcolor="#d0ffd0" cellpadding="18"><tr><td>
<h3>Best practices and known limitations</h3>
<ul>
<li>Virtual Tables are not really genuine Database Tables, they are just emulating the original source as a Database Table.</li>
<li>Virtual Tables have very poor speed performances, due to the  emulation, as compared to genuine Database Tables.</li>
<li>Complex SQL queries <b>JOIN</b>ing several Tables can often return odd and misleading resultsets, when one or more of the <b>JOIN</b>ed Tables are of the Virtual type.</li>
<li>The best use of a Virtual Table is to preform a basic data import process, or to quickly get an overall glance at a full dataset without necessarily importing it into the Database.</li>
<li>Pretending to use a Virtual Table as a full replacement of importing all data within a genuine Database Table is strongly discouraged, and never is a good idea.</li>
</ul><br>
<b>Warning</b>: VirtualShape Tables are always subject to <b>READ-ONLY</b> restrictions. Any attempt to to execute an <b>INSERT</b>, <b>UPDATE</b> or <b>DELETE</b> statement will always return an error.<br>

<br>
<table bgcolor="#e0e0e0" cellpadding="18"><tr><td>
<h3>Related Topics</h3>
<ul>
<li>The <b>ImportSHP()</b> SQL function allows to create and populate a genuine Spatial Table by importing an external Shapefile.</li>
<li>And the <b>ExportSHP()</b> sister function allows the exportation a whole Spatial Table into an external Shapefile.</li>
</ul>

<br>
<hr>
<h1><a
The <b>VirtualDBF</b> Interface allows to directly access an external DBF table by using standard Spatial SQL queries.<br>
Syntax for creating a VirtualDbf Table:
<verbatim>
SELECT CREATE VIRTUAL TABLE my_table USING VirtualDbf ( dbf_path , charset_encoding );

SELECT CREATE VIRTUAL TABLE my_table USING VirtualDbf ( dbf_path , charset_encoding , text_dates );

SELECT CREATE VIRTUAL TABLE my_table USING VirtualDbf ( dbf_path , charset_encoding , text_dates , colname_case );
</verbatim>
Supported arguments and their interpretation:
<ul>
<li><b>dbf_path</b> the relative or absolute pathname leading to the external DBF file.
<ul>
<li><b>Note</b>: the full pathname must be passed, including the final <i>*.dbf</i> suffix.</li>

<li><b>charset_encoding</b> canonical name of the charset encoding adopted by the <b>DBF</b> member.
<ul>
<li>Examples of valid names are: <b>ASCII</b>, <b>UTF-8</b>, <b>CP850</b>, <b>CP1252</b>,
<li>You can check the full list of supported charset encodings <a

<li><b>text_dates</b> this is a <b>BOOLEAN</b> flag:
<ul>
<li>if set to <b>0</b> (<b>FALSE</b>) all fields of the <b>DATE</b> type will be represented as <a
<li>if set to any other integer value (<b>TRUE</b>) all fields of the <b>DATE</b> type will be represented as Text Strings as e.g.
<li>if not explicitly specified, <b>TRUE</b> will always be assumed (default setting).</li>

<li><b>colname_case</b> this argument specifies if all column names should be considered uppercase or lowercase.<br>
Valid settings are:
<ul>
<li><b>uppercase</b> or <b>upper</b>: all column names will be fully capitalized.</li>
<li><b>lowercase</b> or <b>lower</b>: all column names will be full lowercase.</li>
<li><b>samecase</b> or <b>same</b>: all column names will be exactly preserved as they are defined into the DBF member.</li>
<li>if not specified, or if any other definition definition is found, <b>lowercase</b> will always be assumed (default setting).</li>

</ul><br>
<table bgcolor="#ffffd0" cellpadding="18"><tr><td>
<b>Note</b>: any Text String, quoted or not, when it appears as a Virtual Table argument has the same effect.
<verbatim>
SELECT CREATE VIRTUAL TABLE my_table USING VirtualDbf( , CP1252 , 1 , lower );
or
SELECT CREATE VIRTUAL TABLE my_table USING VirtualDbf( , 'CP1252' , 1 , 'lower' );
</verbatim>
Both notations will produce the same result.

<br>
<table bgcolor="#d0ffd0" cellpadding="18"><tr><td>
<h3>Best practices and known limitations</h3>
<ul>
<li>Virtual Tables are not really genuine Database Tables, they are just emulating the original source as a Database Table.</li>
<li>Virtual Tables have very poor speed performances, due to the  emulation, as compared to genuine Database Tables.</li>
<li>Complex SQL queries <b>JOIN</b>ing several Tables can often return odd and misleading resultsets, when one or more of the <b>JOIN</b>ed Tables are of the Virtual type.</li>
<li>The best use of a Virtual Table is to preform a basic data import process, or to quickly get an overall glance at a full dataset without necessarily importing it into the Database.</li>
<li>Pretending to use a Virtual Table as a full replacement of importing all data within a genuine Database Table is strongly discouraged, and never is a good idea.</li>
</ul><br>
<b>Warning</b>: VirtualDBF Tables are always subject to <b>READ-ONLY</b> restrictions. Any attempt to to execute an <b>INSERT</b>, <b>UPDATE</b> or <b>DELETE</b> statement will always return an error.<br>

<br>
<table bgcolor="#e0e0e0" cellpadding="18"><tr><td>
<h3>Related Topics</h3>
<ul>
<li>The <b>ImportDBF()</b> SQL function allows to create and populate a genuine Database Table by importing an external DBF file.</li>
<li>And the <b>ExportDBF()</b> sister function allows to directly export a whole Database Table into an external DBF file.</li>
</ul>

<br>
<hr>
<h1><a
The <b>VirtualText</b> Interface allows to directly access an external Text file by using standard Spatial SQL queries.<br>
The Text File is expected to contain a properly formatted Table accordingly to some <b>Delimiter-Separated-Values</b> format (comma separated values <i>*.csv</i>, tab separated values <i>*.txt</i> and alike).<br>
Syntax for creating a VirtualText Table:
<verbatim>
SELECT CREATE VIRTUAL TABLE my_table USING VirtualText ( textfile_path , charset_encoding );

SELECT CREATE VIRTUAL TABLE my_table USING VirtualText ( textfile_path , charset_encoding , first_row_as_titles );

SELECT CREATE VIRTUAL TABLE my_table USING VirtualText ( textfile_path , charset_encoding , first_row_as_titles , decimal_separator );

SELECT CREATE VIRTUAL TABLE my_table USING VirtualText ( textfile_path , charset_encoding , first_row_as_titles , decimal_separator , text_separator );

SELECT CREATE VIRTUAL TABLE my_table USING VirtualText ( textfile_path , charset_encoding , first_row_as_titles , decimal_separator , text_separator , field_separator );
</verbatim>
Supported arguments and their interpretation:
<ul>
<li><b>textfile_path</b> the relative or absolute pathname leading to the external Text file.
<ul>
<li><b>Note</b>: the full pathname must be passed, including an eventual final suffix (<i>*.txt</i>, <i>*.csv</i> and alike).</li>

<li><b>charset_encoding</b> canonical name of the charset encoding adopted by the Text file.
<ul>
<li>Examples of valid names are: <b>ASCII</b>, <b>UTF-8</b>, <b>CP850</b>, <b>CP1252</b>,
<li>You can check the full list of supported charset encodings <a

<li><b>first_row_as_titles</b> this is a <b>BOOLEAN</b> flag:
<ul>
<li>if set to <b>0</b> (<b>FALSE</b>) all column names will be automatically set by using a progressive sequence.</li>
<li>if set to any other integer value (<b>TRUE</b>) all column names will by expected to be defined in the very first row of the Text file.</li>
<li>if not explicitly specified, <b>TRUE</b> will always be assumed (default setting).</li>

<ul>

<li><b>decimal_separator</b> the character acting as a separator between the integer and decimal parts of a number.<br>
Valid values are any printable character or the special mnemonic notations <b>POINT</b> or <b>COMMA</b>.<br>
If not explicitly specified, <b>POINT</b> will always be assumed (default setting)</li>
<li><b>text_separator</b> the character acting as a string delimiter.<br>
Valid values are any printable character or the special mnemonic notations <b>SINGLEQUOTE</b>, <b>DOUBLEQUOTE</b> or <b>NONE</b>.<br>
If not explicitly specified, <b>DOUBLEQUOTE</b> will always be assumed (default setting)</li>
<li><b>field_separator</b> the character acting as a delimiter between consecutive fields.<br>
Valid values are any printable character or the special mnemonic notations <b>TAB</b>.<br>
If not explicitly specified, <b>TAB</b> will always be assumed (default setting)</li>
</ul><br>
<table bgcolor="#ffffd0" cellpadding="18"><tr><td>
<b>Note</b>: any Text String, quoted or not, when it appears as a Virtual Table argument has the same effect.
<verbatim>
SELECT CREATE VIRTUAL TABLE my_table USING VirtualText( , CP1252 , 1 , POINT , NONE , TAB );
or
SELECT CREATE VIRTUAL TABLE my_table USING VirtualText( , 'CP1252' , 1 , 'POINT' , 'NONE' , 'TAB' );
</verbatim>
Both notations will produce the same result.

<br>
<table bgcolor="#d0ffd0" cellpadding="18"><tr><td>
<h3>Best practices and known limitations</h3>
<ul>
<li><b>Be aware</b>: opening big or huge text files could easily require massive RAM allocations.</li>
<li><b>Warning</b>: attempting to access an external Text file by blindly specifying randomly chosen delimiters or separators may easily have catastrophic effects.<br>
Always carefully check the actual structure of the Text file before attempting to access it.</li>
<li>Virtual Tables are not really genuine Database Tables, they are just emulating the original source as a Database Table.</li>
<li>Virtual Tables have very poor speed performances, due to the  emulation, as compared to genuine Database Tables.</li>
<li>Complex SQL queries <b>JOIN</b>ing several Tables can often return odd and misleading resultsets, when one or more of the <b>JOIN</b>ed Tables are of the Virtual type.</li>
<li>The best use of a Virtual Table is to preform a basic data import process, or to quickly get an overall glance at a full dataset without necessarily importing it into the Database.</li>
<li>Pretending to use a Virtual Table as a full replacement of importing all data within a genuine Database Table is strongly discouraged, and never is a good idea.</li>
</ul><br>
<b>Warning</b>: VirtualText Tables are always subject to <b>READ-ONLY</b> restrictions. Any attempt to to execute an <b>INSERT</b>, <b>UPDATE</b> or <b>DELETE</b> statement will always return an error.<br>

<br>
<table bgcolor="#e0e0e0" cellpadding="18"><tr><td>
<h3>Related Topic</h3>
Reasons for lack of a <i>ImportCSV()</i> function:
<ul>
<li>Based on the fact that CSV and TXT/TAB are very loose and variable defined format, successfully opening and reading a Text file usually requires several attempts before you finally "guess" the most appropriate combination of
<li>Therefore a 2 step import process is advised:</li>
</ul>
<verbatim>
----------------------------------------
-- Step 1: create a virtual table using VirtualText
----------------------------------------
CREATE VIRTUAL TABLE virtual_cities1000 USING VirtualText
(
    'cities1000.txt',   -- absolute or relative path leading to the textfile
    'UTF-8',            -- charset encoding used by the textfile
    0,                  -- does the first line contains column names [0=no, 1=yes]
    POINT,              -- the decimal separator [POINT or COMMA]
    NONE,               -- the text separator [NONE, SINGLEQUOTE or DOUBLEQUOTE]
    TAB                 -- the field separator [TAB, ',', ':' or other charater]
);
----------------------------------------
</verbatim>
At this point, a <b>thorough check</b> of the results is needed:
<ul>
<li>do the column names make sense?</li>
<li>are the dates correct?</li>
<li>are the special characters correct ? (needed correction of charset encoding)</li>
<li>is all the data really needed ?
<ul>
<li>what filters are needed to import the needed data ?</li>

</ul>
<verbatim>
----------------------------------------
-- Step 2: create a final TABLE using the virtual table source
----------------------------------------
CREATE TABLE cities_italy AS SELECT
    COL002 AS name,
    COL006 AS longitude,
    COL005 AS latitude,
    MakePoint(COL006, COL005, 4326) AS geom_wsg84,                          -- create the original POINT as Wgs84
    ST_Transform(MakePoint(COL006, COL005, 4326),32632) AS geom_utm_19n     -- create the  POINT as WGS 84 / UTM zone 32N, which the other tables use
FROM virtual_cities1000 WHERE COL009 = 'IT'                                 -- filter out all non-italien cities
;

----------------------------------------
-- such Geometries, created on the fly, must be registered:
----------------------------------------
SELECT RecoverGeometryColumn
(
    'cities_italy',         -- table-name
    'geom_wsg84',           -- geometry column-name
    4326,                   -- srid of geometry
    'POINT',                -- geometry-type
);
SELECT RecoverGeometryColumn('cities_italy','geom_utm_19n',32632,'POINT');

----------------------------------------
-- Create a Spatial-Index for the Geometries
----------------------------------------
SELECT CreateSpatialIndex
(
    'cities_italy',         -- table-name
    'geom_wsg84'            -- geometry column-name
);
SELECT CreateSpatialIndex('cities_italy','geom_utm_19n');

----------------------------------------
-- Update the metadata for the Database
----------------------------------------
SELECT UpdateLayerStatistics
(
    'cities_italy',         -- table-name
    'geom_wsg84'            -- geometry column-name
);
SELECT UpdateLayerStatistics('cities_italy','geom_utm_19n');

----------------------------------------
DROP TABLE IF EXISTS virtual_cities1000 ;
----------------------------------------
</verbatim>

<br>
<hr>
<h1><a
The <b>VirtualXL</b> Interface allows to directly access an external MS Excel spreadsheet (Legacy binary format <b>*.xls</b>, i.e. not  <b>*.xlsm</b> or 'LibreOffice Calc' <b>*.ods</b> files)  by using standard Spatial SQL queries.<br>
Syntax for creating a VirtualXL Table:
<verbatim>
SELECT CREATE VIRTUAL TABLE my_table USING VirtualXL ( xls_path );

SELECT CREATE VIRTUAL TABLE my_table USING VirtualXL ( xls_path , worksheet_index );

SELECT CREATE VIRTUAL TABLE my_table USING VirtualXL ( xls_path , worksheet_index , first_row_as_titles );
</verbatim>
Supported arguments and their interpretation:
<ul>
<li><b>xls_path</b> the relative or absolute pathname leading to the external MS Excel spreadsheet (old binary format
<li><b>worksheet_index</b> the index identifying one of the worksheets within the Excel document.<br>
MS Excel may contain more than one worksheet, and each individual worksheet is identified by its own index (<b>zero-based</b> index; the first worksheet always has <b>index=0</b>).<br>
If not explicitly specified the first worksheet will always be assumed (default value).</li>
<li><b>first_row_as_titles</b> this is a <b>BOOLEAN</b> flag:
<ul>
<li>if set to <b>0</b> (<b>FALSE</b>) all column names will be automatically set by using a progressive sequence.</li>
<li>if set to any other integer value (<b>TRUE</b>) all column names will by expected to be defined in the very first row of the Spreadsheet.</li>
<li>if not explicitly specified, <b>TRUE</b> will always be assumed (default setting).</li>

<ul>

</ul><br>
<table bgcolor="#ffffd0" cellpadding="18"><tr><td>
<b>Note</b>: any Text String, quoted or not, when it appears as a Virtual Table argument has the same effect.
<verbatim>
SELECT CREATE VIRTUAL TABLE my_table USING VirtualXL( , 3, 1 );
or
SELECT CREATE VIRTUAL TABLE my_table USING VirtualXL( , 3, 1 );
</verbatim>
Both notations will produce the same result.

<br>
<table bgcolor="#d0ffd0" cellpadding="18"><tr><td>
<h3>Best practices and known limitations</h3>
<ul>
<li>Virtual Tables are not really genuine Database Tables, they are just emulating the original source as a Database Table.</li>
<li>Virtual Tables have very poor speed performances, due to the  emulation, as compared to genuine Database Tables.</li>
<li>Complex SQL queries <b>JOIN</b>ing several Tables can often return odd and misleading resultsets, when one or more of the <b>JOIN</b>ed Tables are of the Virtual type.</li>
<li>The best use of a Virtual Table is to preform a basic data import process, or to quickly get an overall glance at a full dataset without necessarily importing it into the Database.</li>
<li>Pretending to use a Virtual Table as a full replacement of importing all data within a genuine Database Table is strongly discouraged, and never is a good idea.</li>
</ul><br>
<b>Warning</b>: VirtualXL Tables are always subject to <b>READ-ONLY</b> restrictions. Any attempt to to execute an <b>INSERT</b>, <b>UPDATE</b> or <b>DELETE</b> statement will always return an error.<br>

<br>
<table bgcolor="#e0e0e0" cellpadding="18"><tr><td>
<h3>Related Topics</h3>
The <b>ImportXLS()</b> SQL function allows to create and populate a genuine Database Table by importing an external MS Excel spreadsheet.

<br>
<hr>
<h1><a
The <b>VirtualFDO</b> Interface allows to directly access a Spatial Table containing <b>FDO binary Geometries</b> exactly as if was a SpatiaLite's own native Table.<br>
FDO is an alternative binary format for Geometries stored within a SQLite Database; you can eventually read the <a 16</a> specification for more details.<br>
Syntax for creating a VirtualFDO Table:
<verbatim>
SELECT CREATE VIRTUAL TABLE my_table USING VirtualFdo ( table_name );
</verbatim>
Supported argument and its interpretation:
<ul>
<li><b>table_name</b> the name of the Table in the current Database containing one or more FDO Geometry Columns to be automatically translated to/from SpatiaLite's own native binary BLOB-format.</li>
</ul><br>
<table bgcolor="#ffffd0" cellpadding="18"><tr><td>
<b>Note</b>: any Text String, quoted or not, when it appears as a Virtual Table argument has the same effect.
<verbatim>
SELECT CREATE VIRTUAL TABLE my_table USING VirtualFdo( my_parcels );
or
SELECT CREATE VIRTUAL TABLE my_table USING VirtualFdo( 'my_parcels' );
</verbatim>
Both notations will produce the same result.

<br>
<table bgcolor="#d0ffd0" cellpadding="18"><tr><td>
<h3>Best practices and known limitations</h3>
<ul>
<li>Virtual Tables are not really genuine Database Tables, they are just emulating the original source as a Database Table.</li>
<li>Virtual Tables have very poor speed performances, due to the  emulation, as compared to genuine Database Tables.</li>
<li>Complex SQL queries <b>JOIN</b>ing several Tables can often return odd and misleading resultsets, when one or more of the <b>JOIN</b>ed Tables are of the Virtual type.</li>
<li>The best use of a Virtual Table is to preform a basic data import process, or to quickly get an overall glance at a full dataset without necessarily importing it into the Database.</li>
<li>Pretending to use a Virtual Table as a full replacement of importing all data within a genuine Database Table is strongly discouraged, and never is a good idea.</li>
</ul><br>
<b>Note</b>: VirtualFDO Tables support unrestricted <b>READ-WRITE</b> operations, this including executing <b>INSERT</b>, <b>UPDATE</b> and <b>DELETE</b> statements.<br>

<br>
<hr>
<h1><a
The <b>VirtualGPKG</b> Interface allows to directly access Spatial Tables from a <b>GeoPackage Database</b> exactly as if was a SpatiaLite's own native Database.<br>
GeoPackage (<i>aka</i> <b>GPKG</b>) is an alternative Spatial Database built on the top of SQLite; you can eventually read the <a specification</a> for more details.<br>
Syntax for creating a VirtualFDO Table:
<verbatim>
SELECT CREATE VIRTUAL TABLE my_table USING VirtualGpkg ( table_name );
</verbatim>
Supported argument and its interpretation:
<ul>
<li><b>table_name</b> the name of the Table in the current Database containing one or more GPKG Geometry Columns to be automatically translated to/from SpatiaLite's own native binary BLOB-format.</li>
</ul><br>
<table bgcolor="#ffffd0" cellpadding="18"><tr><td>
<b>Note</b>: any Text String, quoted or not, when it appears as a Virtual Table argument has the same effect.
<verbatim>
SELECT CREATE VIRTUAL TABLE my_table USING VirtualGpks( my_parcels );
or
SELECT CREATE VIRTUAL TABLE my_table USING VirtualGpkg( 'my_parcels' );
</verbatim>
Both notations will produce the same result.

<br>
<table bgcolor="#d0ffd0" cellpadding="18"><tr><td>
<h3>Best practices and known limitations</h3>
<ul>
<li>Virtual Tables are not really genuine Database Tables, they are just emulating the original source as a Database Table.</li>
<li>Virtual Tables have very poor speed performances, due to the  emulation, as compared to genuine Database Tables.</li>
<li>Complex SQL queries <b>JOIN</b>ing several Tables can often return odd and misleading resultsets, when one or more of the <b>JOIN</b>ed Tables are of the Virtual type.</li>
<li>The best use of a Virtual Table is to preform a basic data import process, or to quickly get an overall glance at a full dataset without necessarily importing it into the Database.</li>
<li>Pretending to use a Virtual Table as a full replacement of importing all data within a genuine Database Table is strongly discouraged, and never is a good idea.</li>
</ul><br>
<b>Note</b>: VirtualGPKG Tables support unrestricted <b>READ-WRITE</b> operations, this including executing <b>INSERT</b>, <b>UPDATE</b> and <b>DELETE</b> statements.<br>

<br>
<hr>
<br>
<a to main page</a>