Omnidex Environments

When defining tables that correspond to Oracle tables, define one TABLE for each Oracle table that you want to access through OmniAccess. Use the table names as defined in the SQL* Plus CREATE TABLE command when declaring the TABLE name or the PHYSICAL attribute. Declare any TABLE's TYPE as RELATIONAL.

Defining COLUMNs

The table below lists the supported Oracle data types and their equivalent environment catalog COLUMN TYPEs. Omnidex keys can be installed on any of the following types of fields:

Oracle Data Type Attribute	Field Type	Omnidex Environment Catalog COLUMN Type
NUMBER	unsigned integer of one, two or four bytes	UNSIGNED INTEGER
NUMBER	signed integer of two or four bytes	SIGNED INTEGER
NUMBER	floating point decimal of four or eight bytes	FLOAT
CHAR	fixed character string	CHARACTER
VARCHAR or VARCHAR2 LENGTH n	variable character string	C STRING LENGTH n+1
DATE	Oracle date default format: DD-MON-YY (12-AUG-94)	ORACLE DATETIME LENGTH 7
DATETIME	Any of the datetime formats supported for the OMNIDEX FORMAT clause of a COLUMN statement	ORACLE DATETIME
RAW LENGTH n or LONG RAW LENGTH n	unstructured data (graphics, for example)	CHARACTER LENGTH 2n
RAW and LONG RAW are supported in a limited capacity. Data is returned in hexadecimal-like notation with each byte represented by two hex digits.
LONG LENGTH n	LONG	CHARACTER LENGTH 2n
ROWID	row identifier	CHARACTER LENGTH 18 or ROWID LENGTH n

top

Tidmaps

Supplying Record Pointers

For Omnidex to find the native rows you qualify in a MDK search or ASK search, you must maintain pointers to them in the Omnidex indexes. You can do this either by using native row IDs and TIDMAPs, or by designating a column that uniquely identifies rows in a table to act as a ROWID in the environment catalog.

Converting row IDs: TIDMAP Configuration

TIDMAPs tell Omnidex how to interpret record pointers for any table defined in an Omnidex Environment Catalog without incurring the update overhead of a cross-reference table or an additional native index. TIDMAP information is necessary to convert Oracle row IDs into pointers that are usable to Omnidex for indexing and retrieval.

TIDMAPs do not require the additional disc space and indexing of an identity column.
TIDMAPs offer better indexing and retrieval performance

A default TIDMAP setting is automatically calculated for any given table. In most cases, this TIDMAP setting effectively converts row IDs to record pointers that Omnidex can use. Some tables, however, require you to calculate and declare custom TIDMAP values. This can happen when you add a large volume of data to a table, or change the way data is stored.

If the internally calculated TIDMAP for a table is wrong, an OmniAccess update application or utility program, like DBINSTAL, may return this error:

Rowids from this table cannot be mapped into record numbers

When you get the error shown above, call the DISC Response Center at (303) 444-6610. A response center representative will help you determine the best TIDMAP for your installation.

Declaring TIDMAP Values for a Table

After the response center representative has given you TIDMAP values, you must declare them in the environment catalog source file where the table in question is defined.

In rare cases, your data may not permit you to calculate TIDMAP values. When this happens, you must create an identity column to use as a redefinable row ID.

Be sure to recompile the environment catalog. You must also reindex any domains where TIDMAPs have changed, as well as any ASK keys installed in them. A domain consists of a parent table and any child tables prejoined to it during OMNIDEX installation.

top

Getting ROWIDs for Index-Only Updates

When using index-only update routines to successfully reflect a native update (deletion, insertion or update) in the OMNIDEX indexes, you must supply the native row's ID value to the oadeleteindex, oainsertindex or oaupdateindex routine. Oracle provides a logical column, called "rowid", that you can name in the column list of an OmniAccess oaselect call or a SQL SELECT statement. You can SELECT ROWID INTO a variable and reference it in the oadeleteindex, oainsertindex or oaupdateindex routine, or you can include the logical column ROWID in your oaselect column list prior to retrieving rows with oafetch.

Oracle guarantees that the row ID for any given record will not change if that record is updated. Therefore, when using oaupdateindex in an Oracle application, you can use the same variable for the before_rowid and the after_rowid.

top

Omnidex ROWIDs

If the table you are defining contains a uniquely assigned, sequentially ascending four-byte integer value, you can use that value to identify rows for OMNIDEX indexing and retrieval.

Native Data Considerations

For a column to be eligible for identifying rows for OMNIDEX indexing and retrieval, it must have been created with the following attributes:

It must be a four-byte number that contains unsigned integer data.
It must have been assigned a UNIQUE constraint.
It need not be indexed if you are performing index-only retrieval of data.

It is also useful if the column has had a SEQUENCE assigned to it to automatically assign a value whenever a new record is added to the table. This prevents applications from having to programmatically determine which values it can write to the column.

If you want to retrieve native rows from the table, the column you want to use as an OMNIDEX row ID must have an Oracle index created for it.

top

Oracle Dates

The Oracle date and datetime data types are declared as type Oracle DATETIME in the Omnidex Environment Catalog. You may also declare a function in the Omnidex attribute for the column which describes how to display the date. The syntax for the function is:

COLUMN SHIP-DATE Oracle DATETIME LENGTH 8
OMNIDEX FORMAT YYMMDDHH

This example returns the century year (the last two digits), the month, day, and hour of day.

top

Setting Oracle Variables

Whenever you access an Oracle table using Omnidex or any of its utilities, you must declare ORACLE environment variables in addition to the OAGLOBAL variable. Before you run Omnidex or one of its utilities on the server, you must issue the following commands at the system prompt.

UNIX: Where path1 reflects the location of oaglabal.env,
path2 reflects the location of the Oracle software you want to use,
and name reflects a valid SID.

export OAGLOBAL="path1/oaglabal.env"
export ORACLE_HOME="path2"
export ORACLE_SID="name"

OpenVMS: Where path1 reflects the location of oaglabal.env,
path2 reflects the location of the Oracle software you want to use,
and name reflects a valid SID.

DEFINE OAGLOBAL "path1"
DEFINE ORA_ROOT "path2"
DEFINE ORA_SID "name"

MPE/iX: Where DISCACCT is the DISC account in which OAGLOBAL resides,
GROUP.ACCOUNT reflects the location of the Oracle databases you want to access,
and n reflects a valid system identifier.

SETVAR OAGLOBAL "OAGLOBAL.PUB.DISCACCT"
SETVAR ORACLE_HOME "GROUP.ACCOUNT"
SETVAR ORACLE_SID "n"

In addition, SQLNET users must issue the following command:

UNIX:
export TNS_ADMIN="network_admin_path"

OpenVMS:
DEFINE TNS_ADMIN 'network_admin_path'

MPE/iX:
SETVAR TNS_ADMIN 'network_admin_path'

top

Oracle Numeric Datatypes

NUMBER is a proprietary datatype invented and used by Oracle to store all numeric datatypes. It encompasses numbers of all sizes and precisions. Oracle will never return data in this datatype, and they don’t publish its format. When using Oracle (even in non-OA Oracle applications that only use Oracle API), a valid numeric datatype, INTEGER, FLOAT, etc..., must be specified. Knowledge of the data is required to pick the correct type.

OAHELPER will always use a FLOAT 8 because that datatype is capable of handling the largest precision and largest numbers. It is recommended, though, that someone with knowledge of the data edit the environment file and alter those values to FLOAT 4, INTEGER 4, INTEGER 2 or INTEGER 1 in order to preserve space and improve OA performance.

top

DISC | Documentation Home