Provides read/write access to feature data in an Oracle-based data store. Supports spatial indexing, long transactions, and persistent locking. A custom API can gather provider information, transmit client services exceptions, list data stores, and create connection objects.

Deletion Restrictions

This section describes restrictions that apply when performing deletion in a schema while using data store provider for Oracle:

• Class Definition cannot be deleted if it has data (objects).
• Class Definition cannot be deleted if another class in the data store has it as its base class.
• Class cannot be deleted if it is referenced by any object property in the data store.
• A data property cannot be deleted if it has any non-null values.
• An object property cannot be deleted if it has data.
• A geometric property cannot be deleted if its containing class has data.

Locking and Long Transactions

The purpose of this section is two-fold. First, it illustrates ways of understanding the subtleties of the interactions between locking and long transactions in an Oracle context. Secondly, it provides concrete examples of those subtleties. An FDO long transaction version is called a workspace in an Oracle context. In this discussion, the FDO phrase "long transaction version" is shortened to "long transaction". A key phrase in the example is "root," which represents permanent data. Any long transaction has a root long transaction as an ancestor. The Oracle Workspace Manager (OWM) name for the FDO root long transaction is "LIVE".

The Autodesk FDO Provider for Oracle creates tables in the FDO data store that are not automatically version-enabled. Therefore, when you create a new Oracle data store using the default options, the resulting table is not version-enabled, so persistent locking and long transaction are not supported.

OWM is used for versioning and persistent locking support. To enable versioning, you must execute the EnableVersioning.sql script in the ../com sub-folder. This will enable the tables for OWM. Use SQL*Plus to execute the scripts.

Before executing the scripts, the following conditions must be true:

• You always connect directly to the Oracle user (or FDO data store) to be processed.
• The Oracle user executing the script has sufficient privileges (this user has been granted the Workspace Manager role WM_ADMIN_ROLE).
• The Oracle user executing the script is the only user processing or accessing the current Oracle user (or FDO data store) during the execution of the script. Otherwise, a script failure may result from a session conflict.