name: this second mandatory argument, of the TEXT type, must contain the name of the Table (or View) to be dropped.When NULL is used: 'MAIN' DB will be implicitly assumed. db-prefix: this first mandatory argument, of the TEXT type, must contain the prefix identifying the attached DB where the Table or View to be dropped is expected to be.Supported arguments with their interpretation: SELECT DropTable(NULL, 'inexistent_table', 1) SELECT DropTable(NULL, 'inexistent_table') ĭropTable exception - not existing table SELECT DropTable('some_db', 'some_table') If SpatiaLite is running against an earlier version both functions will always raise an Exception complaining about the mismatching library version. Let's now see each single SQL function in full details.īoth RenameTable() and RenameColumn() strictly require SQLite3 version 3.25.0 (or greater). More information and practical samples on how to explicitly define columns can be found here: SQLite: CREATE VIEW syntax explicitly declaring columns.Unofficially, any Column not explicitly defined is considered undefined and SQLite will attempt to resolve the old name by looking inside the underlaying TABLE.The explicit declaration of Columns in the CREATE VIEW is (officially) optional.Special Note: SQLite CREATE VIEW syntax explicitly declaring columns:.Will also work on ordinary (non Spatial) Columns, GeoPackage and OGR/FDO Geometries. VIEWs: only the Column-name of the underlaying TABLE used by the VIEW will be renamed.RenameColumn(): can safely rename a Spatial (or non-Spatial), but cannot be used for any kind of View or VirtualTable.Īny depending Trigger, View, Spatial Index, Metadata and Statistics will be properly updated fully preserving the DB layout consistency.This will also work on any ordinary (non Spatial) Table, RasterLite2 Raster Coverage, GeoPackage and OGR/FDO Table. VIEWs: only the name of the underlaying TABLE used by the VIEW will be renamed.RenameTable(): can safely rename a Spatial (or non-Spatial) Table, but cannot be used for any kind of View or VirtualTable.Īny dependent Triggers, Views, Spatial Indexes, Metadata and Statistics will be properly updated fully preserving the DB layout consistency.but being closely related to the administration tasks for Spatial Tables/Views has been adapted, replacing the deprecated DropGeoTable() function in full.Note: this function is not directly related to the recent changes introduced by SQLite3 This will also work on any ordinary (non Spatial) Table, RasterLite2 Raster Coverage, VirtualTable, GeoPackage (Vector / Raster Table) and OGR/FDO Table. DropTable(): can safely drop a Spatial Table, Spatial View or Spatial VirtualTable.Īny dependent Triggers, Spatial Views, Spatial Indexes, Metadata and Statistics will be properly removed fully preserving the DB layout consistency.To resolve this issue, a complete set of corresponding SQL functions have been introduced in version 5.0.0 to insure that any Administration tasks needed are done correctly. caused by broken links to all used Metadata Tables entries and Spatial Indices.Therefore any use of ALTER TABLE on any Spatial Table or Column will have no effect on any Administration TABLE, causing the creation of an invalid DB layout
0 Comments
Leave a Reply. |