Oracle Spatial extends the Oracle database with the addition of spatial data management functions. Oracle Spatial provides a spatial geometry type (MDSYS.SDO_GEOMETRY), spatial metadata schema, indexing methods, functions, and implementation rules, which are described below.

NOTE: Oracle Locator is a subset of Oracle Spatial. Oracle Locator includes the SDO_GEOMETRY data type along with some of the functionality provided with Oracle Spatial. Oracle Locator may be used with ArcSDE. Please refer to Oracle's documentation for an explanation of the difference between Oracle Spatial and Oracle Locator. Throughout this topic, "Oracle Locator" can be used in place of references to "Oracle Spatial."

• SDO_GEOMETRY
The Oracle Spatial geometry type SDO_GEOMETRY is implemented using Oracle's extensible object-relational type system. The SDO_GEOMETRY type stores information about a geometry including its geometry type, spatial reference ID, interpolation type (straight versus curved), and coordinate values.
The SDO_GEOMETRY type supports single and multipart point, line, and area geometry. Geometries may be defined as having linear interpolation between coordinates as defined by the OpenGIS Simple Feature Specification. Geometries may also be constructed from circular curves or a combination of both interpolation methods.
Application programs are responsible for properly inserting, updating, and fetching the contents of the SDO_GEOMETRY type using Oracle's object-relational SQL interface. Applications are also responsible for ensuring that the content of each geometry adheres to the rules defined in the Oracle Spatial documentation. Oracle provides geometry validation routines that can be executed after inserting geometries.

NOTE: Oracle's geometry validation routines do not implement precisely the same set of rules as the ArcSDE geometry validation. However, ArcSDE is designed to write SDO_GEOMETRY that satisfies Oracle's validation rules.

• Metadata schema
Information about every SDO_GEOMETRY column should be recorded in the Oracle Spatial metadata schema, although Oracle Spatial does not do this automatically. (The Oracle Spatial metadata schema is exposed for each schema as the view USER_SDO_GEOM_METADATA.) The software that creates SDO_GEOMETRY columns must insert the metadata for those columns. ArcSDE does this for any SDO_GEOMETRY feature classes it creates. The metadata contains the spatial column name, the name of the table it resides in and its owner, the Oracle SRID, the number of dimensions, the range of each dimension, and its coordinate tolerance.
• Spatial indexes
Spatial indexes provide fast access to features based on the location of their geometry. For SDO_GEOMETRY, R-tree spatial indexes are generally the most efficient and easiest to create, and Oracle recommends their use in most situations.
Oracle Spatial provides the Spatial Index Advisor utility to assist in determining the best type of spatial index for a given table. In addition, consult your Oracle Spatial User's Guide and Reference for detailed information on supported spatial index types, how to create them, and the trade-offs of different spatial index methods.
• Spatial functions
Oracle Spatial extends SQL with spatial search functions for primary and secondary filtering. Including the SDO_FILTER function in a SQL query will perform a primary spatial search utilizing the spatial index. Spatial predicates, such as SDO_RELATE and SDO_CONTAINS, return secondary relationships between pairs of SDO_GEOMETRY objects.
Oracle Spatial has spatial transformation functions that change the form of an SDO_GEOMETRY value. For example, the SDO_BUFFER function computes the coordinates of a new SDO_GEOMETRY object as a buffer polygon at a given distance surrounding the original geometry. Other spatial transformation functions include SDO_DIFFERENCE and SDO_INTERSECTION.
• Coordinate reference and SRID
Oracle Spatial provides access to a number of predefined coordinate reference systems using Spatial Reference Identifier (SRID) values. The SRID value, stored in the SDO_GEOMETRY object, specifies the coordinate reference for the geometry stored in that object. If it is not NULL, the SRID in the SDO_GEOMETRY object is a foreign key into a table containing details about each SRID. This table is called MDSYS.CS_SRS.
The SDO_TRANSFORM function uses the spatial reference ID to establish coordinate reference transformations. ArcSDE may also use this information to create ArcSDE spatial references.

ArcSDE supports Oracle Spatial or Oracle Locator for storing and managing geometry in an Oracle database. To use it, you must have SDO_GEOMETRY specified for the GEOMETRY_STORAGE parameter of one of your configuration keywords. If you want to use Oracle Spatial geometry storage most of the time, specify SDO_GEOMETRY for the GEOMETRY_STORAGE parameter in your DEFAULTS configuration keyword. If you want to use it for only some datasets, utilize the SDO_GEOMETRY keyword when creating each individual dataset.

Making Oracle Spatial your default geometry schema

When you first install the 9.3 ArcSDE component, ST_Geometry is the default geometry storage type. The default settings for ArcSDE storage are defined in the DBTUNE table by the GEOMETRY_STORAGE parameters.

Changing the default ArcSDE geometry storage to use Oracle Spatial is easy. For the DEFAULTS keyword, change the GEOMETRY_STORAGE parameter from ST_GEOMETRY to SDO_GEOMETRY. After the default GEOMETRY_STORAGE setting has been changed to SDO_GEOMETRY, ArcSDE creates feature classes with SDO_GEOMETRY columns by default.

NOTE: Use the sdedbtune administration command to alter DBTUNE settings. For details on using the sdedbtune command, consult the ArcSDE Administration Command Reference installed with ArcSDE.

ArcSDE for Oracle supports a number of different geometry storage schemas—these different schemas can all be used together in the same database. While there can only be one default geometry schema, individual tables can be created using different geometry schemas.

If you want to store just some of your feature classes with the Spatial Type for Oracle storage, you can specify the keyword SDO_GEOMETRY when you create the feature class. If you do this, that particular feature class will be created with an SDO_GEOMETRY column. In the dbtune file, the SDO_GEOMETRY keyword appears as follows:

##SDO_GEOMETRY
GEOMETRY_STORAGE    "SDO_GEOMETRY"
ATTRIBUTE_BINARY    "BLOB"
RASTER_STORAGE	    "SDO_GEORASTER"
SDO_COMMIT_INTERVAL  1000
UI_TEXT          "User Interface text description for SDO_GEOMETRY"

COMMENT        "Any general comment for SDO_GEOMETRY keyword"

END

Top of page

What happens when you create feature classes with SDO_GEOMETRY geometry storage

When you create a feature class with SDO_GEOMETRY storage, the following happens:

• An SDO_GEOMETRY column is added to the business table of the feature class.
ArcSDE creates a feature class by adding a geometry column to the specified business table. When the GEOMETRY_STORAGE parameter is set to SDO_GEOMETRY, ArcSDE adds an SDO_GEOMETRY column to the business table. In this example, a business table named Countries has name and population properties-after adding a geometry column, it also has an SDO_GEOMETRY column named Borders. If needed, a unique feature identifier column (called OBJECTID in the following example) is added and populated.



Name	Data type	Null?
NAME	VARCHAR2(32)*
POPULATION	NUMBER(11)
BORDERS	MDSYS.SDO_GEOMETRY
OBJECTID	NUMBER(38)	NOT NULL

*NVARCHAR2(32) if using Unicode strings
A geometry column can be added to the business table using ArcCatalog, the sdelayer administration utility, or the ArcSDE C and Java APIs.
• A spatial index is created on the SDO_GEOMETRY column.
When an SDO_GEOMETRY column is added to a business table, a spatial index on that geometry column is usually created. By default, ArcSDE creates an R-tree index on an SDO_GEOMETRY column. (ArcSDE will also support creating Oracle Spatial Fixed and Hybrid indexes, but these are no longer generally recommended by Oracle.) Alternatively, ArcSDE can create feature classes with no spatial index; however, spatial queries cannot be supported until a spatial index is created. Oracle's SDO_FILTER, used by ArcSDE, requires the presence of a spatial index.
You can create a spatial index several ways—in ArcCatalog; with the sdelayer administration utility; using the Oracle Spatial Index Advisor; using SQL; or programmatically using the ArcSDE C and Java APIs.
ArcSDE automatically drops and re-creates Oracle Spatial indexes created by ArcSDE whenever the feature class is switched between LOAD_ONLY_IO and NORMAL_IO mode. Spatial indexes defined by the Oracle Spatial Index Advisor application or created using SQL are not dropped when ArcSDE switches the feature class to LOAD_ONLY_IO mode.
• A record is added to the Oracle Spatial metadata view.
When ArcSDE adds an SDO_GEOMETRY column to a business table, it also adds the required Oracle Spatial metadata record to the USER_SDO_GEOM_METADATA view. This metadata includes the table name, SDO_GEOMETRY column name, spatial reference ID, and coordinate dimension information.
If a third-party application or SQL is used to create the table, the spatial column, and its metadata, and the table is then registered with ArcSDE, ArcSDE will not delete the metadata when unregistering the table with ArcSDE. However, ArcSDE will always delete the metadata when deleting the table, such as it does with the sdetable -o delete command.
• A coordinate dimension is specified.
You can create ArcSDE geometry as 2D (x/y), 2D with measures, 3D (x/y/z), or 3D with measures. When creating new feature classes or adding an SDO_GEOMETRY column to an existing table, ArcSDE places the Oracle Spatial dimension information in the DIMINFO column of the metadata view.
• The x-coordinate is the first dimension.
• The y-coordinate is the second dimension.
• The z-coordinate is the third dimension if the feature class is defined as having elevations.
• The m-coordinate is the last dimension (third or fourth, depending on the presence or absence of a z-coordinate) if the feature class is defined as having measures.
• The SRID of each SDO_GEOMETRY value is set based on the coordinate reference.
Oracle Spatial provides predefined coordinate references in the MDSYS.CS_SRS table. When using ArcSDE to create a new feature class, to set a specific SRID for the SDO_GEOMETRY column, identify the appropriate Oracle Spatial coordinate reference description, then set the feature class's SDO_SRID DBTUNE storage parameter to that value. For example:

#MY_SDO_KEYWORD
GEOMETRY_STORAGE SDO_GEOMETRY
SDO_SRID 8307
. . . (other parameters) . . .
END



If the SDO_SRID storage parameter is not set, ArcSDE sets the SRID of each SDO_GEOMETRY value to NULL, as well as the SRID in the corresponding metadata record.
ArcSDE does not require the Oracle Spatial SRID. ArcSDE maintains the coordinate reference information for each feature class in its own SPATIAL_REFERENCES table independently from Oracle Spatial.
Consult your Oracle Spatial User's Guide and Reference for information on supported coordinate references.
• The SDO_GEOMETRY column is populated.
When storing geometry in the database, ArcSDE populates the SDO_GEOMETRY value from an ArcSDE API object called SE_SHAPE. The SE_SHAPE object can contain simple and complex geometry that may include elevations, measures, CAD data, annotation, and surface patches. The SDO_GEOMETRY data type supports a subset of these geometric properties. Because there is not a one-to-one mapping of the components in the SDO_GEOMETRY and the SE_SHAPE object, ArcSDE follows a set of rules when storing ArcSDE data in Oracle Spatial tables.
• Create four-digit SDO_GTYPE based on the geometry's entity type.
• Set the SDO_SRID to NULL if no Oracle Spatial coordinate reference is provided in a DBTUNE parameter.
• Write coordinate values in the appropriate coordinate reference system.
• Write coordinates in the order x, y, z, and m, defining elevation and measure ordinates only if present in the source SE_SHAPE object.
• If elevations and/or measure ordinates are present in the source SE_SHAPE object, store all coordinates with an elevation and/or measure ordinate.
• Set elevations and measure ordinates to NaN ("Not a Number") if specific coordinates in the geometry contain undefined elevation or measure values.
• Allow measures on any geometry type, not just linestrings. The first and last coordinates need not contain measure values.
• Do not restrict measure values to ascending or descending order.
• Write circular curves to the SDO_GEOMETRY type when the feature class is registered with the CAD entity mask (c); otherwise, convert the curves to densified straight-edged linestrings.
• Convert noncircular arcs (cubic spline, Bezier) to straight-edged linestrings. When the feature class is registered with the CAD entity mask (c), also store the curved representation in SE_ANNO_CAD_DATA.
• Validate all features before writing them to the database. The validation rules are described in the ArcSDE Developer Help.
• Use SDO_POINT to store single part x/y or x/y/z point in the SDO_GEOMETRY object. For other types of point feature classes, store the point vertices in the SDO_ORDINATE_ARRAY.

NOTE: ArcSDE does not support heterogeneous geometry collection in the SDO_GEOMETRY object, and ArcSDE does not encode SDO_ETYPE 0 elements in the SDO_GEOMETRY object. SDO_ETYPE 0 elements are application specific. See "Interoperability considerations" below for more information.

• An additional column is added to the business table if storing CAD and annotation properties.
The SDO_GEOMETRY type cannot store all types of geometric elements that ArcSDE storage must support. When storage for these elements is required (as determined from the geometry type flags specified when the feature class is created), ArcSDE adds a column called SE_ANNO_CAD_DATA to the business table. Using the Counties feature class example from above, the business table would now contain the following:



Name	Data type	Null?
NAME	VARCHAR2(32)*
POPULATION	NUMBER(11)
BORDERS	MDSYS.SDO_GEOMETRY
SE_ANNO_CAD_DATA	BLOB
OBJECTID	NUMBER(38)	NOT NULL

*NVARCHAR2(32) if using Unicode strings
Whenever ArcSDE detects the data source has CAD data, ArcSDE writes a simple geometric representation of the CAD data into the SDO_GEOMETRY value and writes the unmodified CAD data into the SE_ANNO_CAD_DATA value. If the data source does not have CAD data, ArcSDE sets the SE_ANNO_CAD_DATA value to NULL.
The SE_ANNO_CAD_DATA property contains data from numerous ArcGIS components:
• AutoCAD or MicroStation data from ArcSDE CAD Client
• Parametric objects such as cubic splines and Bezier curves from ArcMap
• Surface patches from ArcMap Spatial Analyst
• Annotation from ArcInfo Workstation (before ArcGIS 8)
• Spatial queries on the feature class are performed using Oracle Spatial filter functions.
ArcSDE uses the Oracle Spatial SDO_FILTER function to perform the primary spatial query. ArcSDE performs secondary filtering of the SDO_GEOMETRY based on the spatial relationship requested by the application.
Applications may also include Oracle Spatial primary and secondary filter functions in the SQL WHERE clause supplied to ArcSDE. Using spatial filters in the WHERE clause, applications can distribute the spatial query to the database server, the ArcSDE application server, and the application itself.

ArcSDE can successfully use tables containing SDO_GEOMETRY columns created externally by other applications or using SQL (sometimes referred to as third-party tables) as long as the tables meet certain prerequisites:

• It must be owned by the user registering the table.
• It must have a single SDO_GEOMETRY column.
• It must have no other columns of a user-defined type.
• It must have a valid entry in the view USER_SDO_GEOM_METADATA.
• It must have a single type of geometry (points, lines, or polygons). Geometry can be multipart.
• It must have an integer, unique, not-NULL column suitable as a registered row ID column.
• It should have a spatial index.
• It should pass Oracle's geometry validation tests; otherwise, accessing these geometries may have unexpected results.
• All the spatial records must have non-null valid number values in the SDO_ORDINATES array.

Performing manual registration of third-party tables containing SDO_GEOMETRY columns

The ArcSDE administration command sdelayer –o register manually registers a table as a feature class. Manually registering tables as feature classes gives you more control over how a table is registered. Here is an example of registering a table called TBL containing point geometries (–e p) in a spatial column called SHAPE. The table has an integer column called PID that will be used as a user-maintained unique feature identifier column (–C pid,USER).

sdelayer –o register –l tbl,shape –e p –C pid,USER –u <user> –p <pw>

To manually register these tables, the prerequisites described above must be met.

Using autoregistration for third-party tables containing SDO_GEOMETRY columns

Autoregistration is a feature of ArcSDE that can find and register unregistered Oracle Spatial tables, allowing ArcSDE to access these tables as feature classes.

Autoregistration is controlled by the ArcSDE initialization parameter DISABLEAUTOREG, which is set to TRUE by default. This means the default state for Autoregistration is "off." To turn on autoregistration, use the following administration command:

sdeconfig –o alter –v DISABLEAUTOREG=FALSE –u sde –p <sde_password>

ArcSDE provides a list of registered feature classes to client applications at certain times, such as when a user connects to the server using ArcCatalog or when running the command sdelayer –o describe. In the process of providing this list, ArcSDE autoregistration searches the Oracle Spatial metadata view, ALL_SDO_GEOM_METADATA, for tables containing SDO_GEOMETRY columns on which the user has SELECT privileges and that are not already registered as feature classes. When a table is discovered that matches these criteria, ArcSDE automatically registers it, making the table available to ArcSDE client applications.

To register the table, ArcSDE must know the geometry type. Autoregistration looks at the first row in a newly discovered table to establish the ArcSDE geometry type. Autoregistration will not register empty tables, but empty tables can be registered manually with sdelayer –o register. If you know the table contains rows with differing geometry types, the sdelayer command can be used to alter the geometry type definition after autoregistration completes. ArcSDE with Oracle Spatial requires a column to identify each row. See "Unique feature identifier column (OBJECTID)." Autoregistration searches for a column in the table to use as a unique feature identifier column. To qualify, the column must be defined as NUMBER(38) UNIQUE NOT NULL. If such a column is found, ArcSDE records it in the ArcSDE table registry as the unique feature identifier column for the table. If a suitable unique feature identifier column is not found, the table is registered, but operations requiring a unique feature identifier are unavailable.

For SDO_GEOMETRY columns that have an Oracle Spatial SRID, ArcSDE stores the information in the ArcSDE SPATIAL_REFERENCES table. ArcSDE sets its spatial reference AUTH_NAME field to ORACLE and the AUTH_SRID field to the SRID value. ArcSDE tests the coordinate reference description and, if it is valid, sets the SRTEXT field to the Oracle Spatial coordinate reference description.

A common misconception is that applications can interoperate simply because they support the same underlying geometry type. However, the geometry type is only one aspect of the geodatabase as well as other GIS database schemas. Gaining a common understanding of rules, constraints, schema, and implementation is also required. Some things you should consider when using Oracle Spatial with ArcSDE and ArcSDE clients are the following:

ArcSDE and ArcGIS do not support multiple geometry columns in a table.

Tables with multiple SDO_GEOMETRY columns should be accessed through views that contain only one SDO_GEOMETRY column.

To use data in an Oracle Spatial table that contains multiple spatial columns, create a spatial view using SQL. This view should only contain one spatial column. Next, register the spatial view with ArcSDE using sdelayer –o register.

To learn how to create and register a view containing only one SDO_GEOMETRY column, see the Knowledge Base article Create an Oracle view of an Oracle Spatial layer (containing multiple geometry columns) and register it with ArcSDE.

ArcSDE and ArcGIS only support a single geometry type in an SDO_GEOMETRY column.

If a single SDO_GEOMETRY column in a table contains multiple geometry types (for example, some records are points and some are polygons), the table cannot be registered with ArcSDE or the geodatabase; the feature class must be registered as containing one geometry type.

Oracle Spatial does not necessarily enforce geometry type constraints on an SDO_GEOMETRY column. Without this enforcement, one application may want to enforce a single geometry type constraint, but another application could insert different geometry types. Beginning with Oracle9i, you have the option to constrain the geometry type on insert into a table with a spatial index creation parameter. For earlier Oracle versions, another option to enforce geometry type constraints is to create an insert-update trigger that checks the SDO_GEOMETRY GTYPE property to enforce geometry types.

Oracle Spatial does not automatically enforce geometry validation on the insert or update of an SDO_GEOMETRY value.

ArcSDE validates geometry when inserting or updating geometries. However, Oracle Spatial itself does not automatically enforce geometry validation on the insert or update of an SDO_GEOMETRY value if you insert or update geometries using methods other than ArcSDE clients, such as SQL.

Problems would occur if illegal or poorly formed geometry values were passed to ArcSDE client applications. To reduce the occurrences of these potential problems, you should validate any geometries created or changed by any method other than an ArcSDE client application.

NOTE: Starting with ArcSDE 9.1, ArcSDE no longer validates SDO_GEOMETRY features as they are fetched from the database. This change was done to improve fetch performance.

There are two tools available for validating geometry. Oracle's VALIDATE_GEOMETRY_WITH_CONTEXT will check geometries using Oracle's shape validation rules, and sdelayer –o feature_info will check them using ArcSDE's rules. The feature_info operation optionally includes as part of its output information on whether or not a shape's geometry is valid for ArcSDE. For details on the use of this operation, please refer to the Administration Command Reference documentation included with your ArcSDE installation.

ArcSDE geometry validation is not the same as Oracle Spatial geometry validation. While it is important that geometries pass Oracle Spatial validation, successfully validating geometries with Oracle's validation routines does not guarantee that the geometries will be validated by ArcSDE.

You can create an insert-update trigger to fire the SDO_VALIDATE function to enforce validation of SDO_GEOMETRY types.

The ArcSDE C API can be used to write an application that retrieves features even if they fail ArcSDE shape validation. However, it is then up to the client application to determine the suitability of the geometry, or how to fix it.

ArcSDE does not support heterogeneous geometry collections in an SDO_GEOMETRY object.

Most applications reading SDO_GEOMETRY objects would not know how to interpret SDO_ETYPE 0 data created by other applications.

Oracle Spatial allows applications to insert application-specific data into an SDO_GEOMETRY object. Applications do this by embedding their data using an SDO_ETYPE value of 0. This allows applications great flexibility to store many types of unconventional geometry and other data. However, the meaning of the application-specific data is known only to the application that generated that special SDO_GEOMETRY object. Such application-specific data cannot be reliably supported in an interoperable environment. Applications reading SDO_GEOMETRY objects probably would not know how to interpret SDO_ETYPE 0 data created by other applications. Applications updating SDO_GEOMETRY objects would not know how to edit or preserve the SDO_ETYPE 0 data.

When reading SDO_GEOMETRY objects containing SDO_ETYPE 0 elements, ArcSDE will ignore the SDO_ETYPE 0 data and will pass only the simple feature geometry elements it supports to the application.

When updating SDO_GEOMETRY objects containing SDO_ETYPE 0 elements, ArcSDE will not preserve the SDO_ETYPE 0 data. Therefore, applications that need to ensure that SDO_ETYPE 0 data is preserved should make sure that users do not have UPDATE access to the table.

ArcSDE requires that all SDO_GEOMETRY values in a column be in the same coordinate reference system.

If the coordinate reference is undefined, the SRID value should be NULL as defined in the Oracle Spatial User's Guide and Reference.

Prior to Oracle9i, Oracle Spatial does not automatically enforce spatial reference ID validation on the insertion or update of an SDO_GEOMETRY value. To enforce validation of SDO_GEOMETRY types on these older Oracle instances, you can create an insert-update trigger to fire the SDO_VALIDATE function. Starting with Oracle9i, Oracle Spatial requires that the SRID in each geometry match each other and the SRID in the spatial metadata, even if it is NULL.

Oracle Spatial and ArcSDE both assume that the first and second dimensions of the SDO_GEOMETRY are x and y, respectively.

If an SDO_GEOMETRY object has three dimensions, ArcSDE assumes the third dimension is a measure if the dimension name (in the spatial metadata) starts with an M; otherwise, the third dimension is assumed to be elevation. You can control how ArcSDE interprets the third dimension by setting the feature class's entity flag to have either elevations or measures.

Oracle9i Release 2 extended the SDO_GTYPE member of the SDO_GEOMETRY type to allow encoding of whichever dimension contains a measure ordinate. The second digit of the four-digit SDO_GTYPE may be 0, 3, or 4. If it is 3 or 4, this indicates which dimension contains the measure ordinate. ArcSDE 9.0 and above recognizes this encoding. Otherwise, if the SDO_GEOMETRY object has four dimensions, the measure is expected to be the last ordinate.

In this example, sdelayer sets the entity type of a feature class to store linestrings and elevations:

sdelayer –o add –e l3

In this example, sdelayer sets the entity type of a feature class to store linestrings and measures:

sdelayer –o add –e lM 

Oracle Spatial (but not Oracle Locator) provides functions for linear reference system (LRS) calculations using measure values.

Oracle Spatial LRS functions require that all measure values in a geometry be monotonically ascending or descending without NaN values. Oracle Spatial LRS also restricts measure values to linestrings.

ArcSDE allows measures and LRS calculations on all geometric types, with support for arbitrarily ordered measure values and NaN values.

If you intend to use Oracle Spatial LRS functions, be sure to design your application and database to operate within the Oracle Spatial LRS constraints.

ArcSDE needs a unique feature identifier in the spatial table to perform spatial queries, log file queries, single-row operations, and multiversioned database operations.

With ArcSDE compressed binary schema, the geometry column can serve this purpose because it is a foreign key into the feature table and is defined as a non-NULL, unique integer value. SDO_GEOMETRY does not include a unique identifying value, so when ArcSDE adds the SDO_GEOMETRY column to an existing table, it may also add a unique identifying column. Such a column is referred to as the registered row ID column. This column is often called OBJECTID, but it can have another name. Or, an existing column can be used for the registered row ID column so long as it is indexed and is an integer, UNIQUE, and NOT NULL. Registered row ID columns maintained by ArcSDE must be NUMBER(38) UNIQUE NOT NULL.

A registered row ID column can be added using the sdetable administration command or the ArcCatalog application. Many applications, such as ArcGIS, require a registered row ID column in each table or feature class. Each application has its own requirements and limitations.

Multiversioned views are available for SQL access to the multiversioned database.

ArcGIS uses a multiversioned database implemented through ArcSDE for editing operations. The multiversioned database provides long transaction support for multiple simultaneous design alternatives.

Multiversioned views are available for SQL access to the multiversioned database, including Oracle Spatial tables registered as versioned. See Using database views for more information.

Modification of Oracle Spatial feature classes participating in networks or topologies should be restricted to ArcGIS applications.

ArcGIS can create and maintain networks and integrated topological feature classes from simple feature classes that use the SDO_GEOMETRY type. ArcGIS manages the relationships and maintains the topological integrity of the data—modifications to the underlying features through ArcGIS are reflected in these integrated networks.

Modification of Oracle Spatial feature classes participating in these networks or topologies should be restricted to ArcGIS applications. Other applications can freely read the data, but any modifications they make are not reflected in the networks or topologies.

Modification of Oracle Spatial feature classes participating in relationships and constraints should be restricted to ArcGIS applications.

ArcGIS enforces relationships and constraints across many different data sources. Feature classes containing an SDO_GEOMETRY type may be included in relationships and may have constraints defined on them.

Modification of Oracle Spatial feature classes participating in relationships and constraints should be restricted to ArcGIS applications. Other applications can freely read the data, but their edits are not properly handled.

Tip

• You can find further information and help with Oracle Spatial issues on the ESRI Online Support Center.