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. (This differs from previous releases.)
OWM is used for versioning and persistent locking support. To enable versioning, you must execute the EnableVersioning.sql script in the /FDO/bin/com folder. This will enable the tables for OWM. Use SQL*Plus to execute the scripts.
Read the documentation contained within the script files themselves to determine what privileges are required for each script, how to run the scripts, and what errors may occur. Severe consequences can occur if you respond incorrectly to any errors you encounter while running a script.
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.
You can create a script log file by executing the spool <log file name>; command before invoking the scripts and the spool off; command after the invoked script finishes. The log file can help you resolve any issues encountered by the scripts.