Registered Tables in Documentum

Registered tables are the tables that are present database which are registered in Documentum, so that it can be accessed using DQL. Basically Registered tables are used when the application needs to access data from the RDBMS within the Documentum. This can be either a Table or a View.  The Scenarios where I mostly used registered tables are for providing value assistance for Object attributes.  I am not getting into too much of details about Value Assistance here, Value assistance is a list of values that a client program (such as Webtop or a Custom WDK Application) displays at runtime for an object attribute. A user can select a value from this list (or, if allowed, add a new one to it). You can set the Value assistance for an Attribute using DAB (Documentum Application Builder).

As I mentioned above uou can register a Table or a view as a Registered Table, The Registered tables are stored as dm_registered objects in repositories. This extends dm_sysobject. And the r_object_id of this type always starts with 19. The following table lists the attributes of dm_registered

Name Info Description
column_count Integer  – Single Number of columns in the table.
column_datatype string(64) – Repeating List of the datatypes of the columns.
column_length. integer R Lengths of the columns that have a string data type
column_name. string(64) – Repeating List of the names of the columns in the table
group_table_permit integer  – Single Defines the RDBMS table permit level assigned to the registered table’s group.
is_key. Boolean Repeating Indicates if an index is built on the column
owner_table_permit integer  – Single Defines the RDBMS table permit level assigned to the registered table’s owner
synonym_for string(254) – Repeating Name of the table in the underlying RDBMS (can be an Oracle table synonym, or an MS SQL Server or Sybase table alias)
table_name string(64) Single Name of the table.
table_owner string(64) Single Name of the owner of the RDBMS table (the person who created the RDBMS table).
world_table_permit integer  – Single Defines the RDBMS table permit level assigned to the world

You should either own the table or have super user privileges to register a table. And since this object is linked with /system cabinet you should have write permission on /system cabinet. This is applicable only if the folder security is enabled in Repository

You cannot version a dm_registered object. And also the changes made to the table are not automatically updated in dm_registered object.  So if any changes has been made to the structure of the table or view you should unregister it first and register the table again with changes.

How to Register a Table?

Use the following DQL to register a table. REGISTER TABLE [owner_name.]table_name (column_def {,column_def}) [[WITH] KEY (column_list)][SYNONYM [FOR] ‘table_identification‘] This DQL will return the r_object_id of the newly created dm_registered object. In this owner_name is the name of the table owner. table_name is the name of the RDBMS table. column_def defines the columns in the registered table.

column_def arguments should have following syntax column_name datatype [(length)] the valid values for types are float, double, integer, int, char, character, string, date, time.

Length should be specified for character, char, or string data type.

column_list Identifies the columns in the table on which indexes have been built. column_list is usually separated with commas. table_ identification is the name of the table in the Database Example:

REGISTER TABLE “hr.users” (first_name CHAR(30), last_name (char 40), emp_id INT)KEY (“emp_id”)

Granting Rights

You need to give the permission to the users to access the registered tables.  The values for various permission levels are as follows 0 (None): No access 1 (Select): The user can retrieve data from the registered table 2 (Update): The user can update existing data in the registered table4 (Insert): The user can insert new data into the registered table8 (Delete): The user can delete rows from the registered table If a user wants update and insert permissions the value should be 2+4 = 6 , The repository owner also should have the same level of permission in the underlying database to grand those permission to those users. Granting Rights full permission to users in the above example

update dm_registered object set world_table_permit = 15 where object_name = ‘users’;

update dm_registered object set owner_table_permit = 15 where object_name =  ‘users’;

update dm_registered object set group_table_permit = 15 where object_name = ‘users’;

How to Unregister a Table?

Use the following DQL to Unregister a Table.

UNREGISTER [TABLE] [owner_name.]table_name In this owner_name is the name of the table owner. table_name is the name of the RDBMS table. You should be the owner of table or super user to do this

Accessing Data from Registered Table

Just like in RDBMS you can access registered table using the following syntax


The Operations such as update/ delete also has the same RDBMS syntax that’s used for a ordinary SQL, Only difference is prefixing dm_dbo to the table name

Select first_name, last_name, emp_id from dm_dbo.users ;

Updating Data in a Registered Table

Update dm_dbo.users set first_name=’John’ where first_name=’Smith’

Deleting from a Registered Table


Delete from dm_dbo.users  where first_name=’Smith’

Download this note on Registered Table (PDF)

Aspects the new BOF type in Documentum


Aspects, the new member in the BOF family is one among the new additions to the Documentum 6 (D6).  This short notes are just to give you insight to the fundamentals of Aspects.

What is Aspects?

In simple words Aspects are like TBO’s but they are not associated with any object types.  That means you can attach or detach an Aspect at runtime to any object type. In other words Aspects are a mechanism for adding behavior and/or attributes to a Documentum object instance without changing its type definition (From DFC Study Guide)

Aspects like any other BOF types are stored in the repository. When a DFC runtime requests for a Aspect it will be downloaded to that system and used. Aspect belongs to the type dmc_aspect_type.

 Aspects are saved in /System/Modules/Aspect in the repository which has a global registry. If any changes are made to any aspects DFC runtime detects that and downloads the latest version to its local cache of BOF.  

What Aspects can do?

Aspects are different from other BOF’s because it is attached to the Object instance, not to the object types.  They are not a per-application customization. Any Persistent object instance can have multiple aspects attached to it if each aspect has a unique name.

Aspects define custom additional fields and it can set custom values to the fields of any object that of type persistent object. There are no restrictions for the type of and number of attributes that you can create on an aspect.  It can be of any supported types and be either a single value or a repeated value attributes.

Another aspect can access the Attributes defined in one Aspect. The Fully qualified aspects attributes are aspect_name.aspect_value. When you fetch an Object all values of attributes of attached aspects are also fetched.  If you destroy an object it also deletes the attributes in the attached aspect.

Where Can I use it?

Aspects are used when you have a cross type functionality to be defined. When you create a application infrastructure or a corporate platform Aspects are the best way to implement business functionality which is common between different object types. When you have some functionality that is per instance based then also Aspects is the solution.

Lets see a real time scenario where you can use Aspect.

Lets imagine a scenario where you have system, which has user base of different countries, depending upon the country where a user belongs the behavior and fields of the application changes. You can create different aspect, which has the country specific behaviors and fields, and attach it as needed. If the user changes from one country to another simply remove the old country aspect and attach the new country aspect.

 To be Continued ….

Changing the Repository Owner Password in Documentum

Follow thse steps to change the Repository owner password in Documentum Content Server

  1. Stop the Repository
  2. Go to $DM_HOME/dba/config/<repository name>/
  3. Create a copy of the file with name dbpasswd.txt
  4. In the DB change the password of Repository Owner
  5. Edit the dbpasswd.txt( The file backed up in Step 3) and replace the new password as plain text
  6. Save dbpasswd.txt
  7. Go to $DM_HOME/bin run the following
  8. dm_encrypt_password -docbase <docbase name> -rdbms -encrypt <database password>
  9. Restart the Repository

What is the significance of i_vstamp and i_is_replica

These are the properties defined in Persistent Object Type and inherited to all its subtypes

This property is basically used for versioning, each time you save changes to the object the value of this property increases by 1 and this also helps to check the concurrent modification of object.

this property of object that indicates whether that object is replica of  an object in a remote repository

Object Attribute :- Repeated and Single Value Attributes in Database

Documentum Object support 2 types of Attributes

They are 

  • Single Value Attributes
    Single Value properties are properties that can hold a single value at a time
    For  Eg: object_name   One object will have only a single name
  • Repeated Attributes
    Repeated Attributes are properties that can hold multiple values
    For Eg: Keywords  A object can have multiple keywords attached to it

Documentum Uses Underlying database to save the meta-data. ie the Attribute information, Each attribute type in Documentum essentially has 2 tables in the database. One for saving the single value attribute and another one to save repeated attribute.  Documentum uses the following naming convension for the tables,  object_name_s for single value attribute table and object_name_rfor repeated attribute table where object_name is the the name of object type. for example for the dm_sysobject the tables names would me dm_sysobject_s and dm_sysobject_r

Repeated Property

Each property has a column in the _r table with I_position where I_position determines which location it belongs to 
eg:   if my_object has 2 repeated attributes given_names and location the my_object_r will have following columns r_object_id, i_postion, given_names, location

Single Value Attribute
Single Value Attribute is defined as each attribute has single column in the _s table
eg: if my_object has two single attributes surname and sex r_object_id, surname, sex  columns in the my_object_s will be r_object_id, surname, sex

View :- Each object type has 2 views
_SV & SP – All Single value attributes in conjunction with all super types
_RV & RP – All Repeated value attributes in conjunction with all super types
eg: if my_object is extending dm_document views will have all the single / repeated attributes of dm_sysobject,dm_document and my_object (dm_document will be added only if any new attributes has been added to it ) by default dm_document does not have any single attribute or repeated attribute

What is the Difference Between Cabinets and Folders

When I started with Documentum one among the first confusions that I had was this.  Let me explain how are they different.

A Cabinet object is the highest level of Organization visible to the users in a Repository. Means Cabinets can exist only in the top level in the Repository. Cabinet object extends from Folder. But Any object that extends from dm_sysobject (ie means any object that can be saved in a repository) are stored in Cabinets. A Cabinet cannot be placed inside another cabinet or a folder and you need super user privileges to create or remove a Cabinet. But a user who has write access to cabinet can modify the attributes of a cabinet.
The Internal name of Cabinet is dm_cabinet and the r_object_id of cabinet always starts with “0c”

For Understanding Cabinets better,  you can compare the Drive letters of your Home PC as a Cabinet. A Drive is always in the top level in the hierarchy. and you cannot save any data above the Drive level but you can create files in a Drive or in any folders located in the drive.

The Folders are means of organizing objects that can be saved (Any object that extends from dm_sysobject other than dm_cabinet) and it is used with combination of a Cabinet. In other words a Folder cannot exist without a Cabinet. All objects that are saved in a repository must be saved either in a folder, which is inside a cabinet, or it can be saved directly in a cabinet.
Folder extends from dm_sysobject and the internal name of folder is dm_folder and r_object_id of a dm_folder starts with “0b”

An object has to be linked with a folder and it can be linked with multiple folders