|Oracle® Spatial User's Guide and Reference
10g Release 1 (10.1)
Part Number B10826-01
The SDO_MIGRATE.TO_CURRENT procedure described in this chapter lets you upgrade spatial geometry tables from previous releases of Spatial.
SDO_MIGRATE.TO_CURRENT is the only procedure that you should use for upgrading. Do not use the SDO_MIGRATE.TO_81X, SDO_MIGRATE.FROM_815_TO_81X, or SDO_MIGRATE.TO_734 procedures, which were documented in previous Spatial releases but are no longer supported.
Format (Any Object-Relational Model Implementation to Current)
tabname IN VARCHAR2
[, column_name IN VARCHAR2]);
tabname IN VARCHAR2,
column_name IN VARCHAR2
[, commit_int IN NUMBER]);
Format (Any Relational Model Implementation to Current)
layer IN VARCHAR2,
newtabname IN VARCHAR2,
gidcolumn IN VARCHAR2,
geocolname IN VARCHAR2,
layer_gtype IN VARCHAR2,
updateflag IN VARCHAR2);
Upgrades data from a previous Spatial release to the current release. The format depends on whether you are upgrading from the Spatial relational model (release 8.1.5 or lower) or object-relational model (release 8.1.6 or higher). See the Usage Notes for the model that applies to you.
You should use this procedure for any spatial data upgrade. Do not use the SDO_MIGRATE.TO_81X, SDO_MIGRATE.FROM_815_TO_81X, or SDO_MIGRATE.TO_734 procedures, which were documented in previous Spatial releases but are no longer supported.
Table with geometry objects.
tabname that contains geometry objects. If
column_name is not specified or is specified as null, the column containing geometry objects is upgraded.
Number of geometries to upgrade before Spatial performs an internal commit operation. If
commit_int is not specified, no internal commit operations are performed during the upgrade.
If you specify a
commit_int value, you can use a smaller rollback segment than would otherwise be needed.
Name of the layer to be upgraded.
Name of the new table to which you are upgrading the data.
Name of the column in which to store the GID from the old table.
Name of the column in the new table where the geometry objects will be inserted.
One of the following values: POINT or NOTPOINT (default).
If the layer you are upgrading is composed solely of point data, set this parameter to POINT for optimal performance; otherwise, set this parameter to NOTPOINT. If you set the value to POINT and the layer contains any nonpoint geometries, the upgrade might produce invalid data.
One of the following values: UPDATE or INSERT (default).
If you are upgrading the layer into an existing populated attribute table, set this parameter to UPDATE; otherwise, set this parameter to INSERT.
Usage Notes for Object-Relational Model Upgrade
All geometry objects in
tabname will be upgraded so that their SDO_GTYPE and SDO_ETYPE values are in the format of the current release:
SDO_ETYPE values are as discussed in Section 2.2.4.
The procedure also orders geometries so that exterior rings are followed by their interior rings, and saves them in the correct rotation (counterclockwise for exterior rings, and clockwise for interior rings).
Usage Notes for Relational Model Upgrade
Consider the following when using this procedure:
The new table must be created before calling this procedure.
The procedure converts geometries from the relational model to the object-relational model.
A commit operation is performed by this procedure.
If any of the upgrade steps fails, nothing is upgraded for the layer.
layer is the underlying layer name, without the _SDOGEOM suffix.
The old SDO_GID is stored in
SDO_ETYPE values are created, using the values discussed in Section 2.2.4.
The procedure orders geometries so that exterior rings are followed by their interior rings, and saves them in the correct rotation (counterclockwise for exterior rings, and clockwise for interior rings).
The following example changes the definitions of geometry objects in the ROADS table from the release 8.1.5 or higher format to the format of the current release.
SQL> execute sdo_migrate.to_current('ROADS');