After you issue the DEFINE TRANSFER statement, the transfer does
not execute until one of the following events occurs:
- The time specified in the corresponding DEFINE SCHEDULE
statement arrives
- You issue a START TRANSFER NOW statement
You cannot alter a transfer using RDO. You must either drop
the transfer and re-create it, or use the SQL ALTER TRANSFER
statement.
You must have READ privilege for the relations and views of a
Oracle Rdb source database that you specify in a DEFINE TRANSFER
statement. Replication Option returns an error message when you
specify relations and views in a DEFINE TRANSFER statement for
which you do not have READ privilege. Replication Option does not
check for READ privilege for relations and views when you specify
a database accessed through the Rdb Transparent Gateways.
You must execute the DEFINE TRANSFER statement outside of the
scope of a transaction. If you issue this statement when a
transaction is outstanding, Replication Option returns an error
message.
You can refer to relations, fields, and views in a DEFINE
TRANSFER statement either implicitly or explicitly. When you
include either the MOVE RELATIONS ALL, SELECT FIELDS ALL, or
MOVE VIEWS ALL clause, you refer to relations, fields, or views
implicitly. Replication Option uses the current definitions
of the relations, fields, and views in the source database and
stores those names explicitly in the transfer definition. You
refer to relations, fields, and views explicitly when you include
the MOVE RELATION, SELECT FIELDS, or MOVE VIEWS clauses and
supply specific relation, field, or view names.
All fields that you name in the record selection expression (RSE)
of the DEFINE TRANSFER statement must also be included in the
SELECT FIELDS clause. If you do not name the fields explicitly
in the SELECT FIELDS select-field-name statement or implicitly
in the select-field-name clause, Replication Option returns
an error message when the transfer executes, indicating that the
field name is not found in the symbol table.
Replication Option transfers those COMPUTED_BY fields that
depend only on the values of a relation in which the field is
defined. You cannot transfer views that contain unsupported
COMPUTED_BY fields. If views that contain unsupported COMPUTED_
BY fields are specified in the move-views-clause of a DEFINE
TRANSFER statement, the transfer definition fails. You need to
redefine the transfer, excluding the views that refer to the
unsupported COMPUTED_BY fields.
Replication Option allows you to transfer views in two ways:
o Using the move-views-clause
Replication Option transfers the definition of the view
when you specify MOVE VIEWS view-name or MOVE VIEWS ALL. You
must also explicitly or implicitly name in the DEFINE TRANSFER
statement all the relations, views, or fields on which the
transferred view definitions are based. The transfer will fail
if any underlying relations, views, or fields are not named.
o Using the move-relations-clause
Replication Option transfers a view by creating a relation
in the target database containing the view's records when
you use the MOVE RELATION clause. This method improves query
performance in the target database. For example, you can
achieve the effect of a CROSS clause by transferring a view
that is a CROSS in the source.
You specify the relations you wish to move in the move-relations-
clause and the views in the move-views-clause of the DEFINE
TRANSFER statement. When you are doing an extraction rollup
transfer, you specify the relations you wish to move in the
move-relations-rollup-clause of the DEFINE TRANSFER statement.
The same clause can occur in a DEFINE TRANSFER statement no more
than once. You cannot specify the same relation or view more than
once in the move clauses. If a relation name or view name appears
in more than one move clause, Replication Option returns an
error.
Individual move-relations clauses are separated by semicolons,
as indicated in the syntax diagrams. You can implement the move-
relations-clause in two ways:
o Specify MOVE RELATIONS ALL
o Specify a series of relations separated by semicolons
The move-relations-clause has the following characteristics and
limitations:
o All fields in each move-relations-clause must reside in the
same relation.
o You cannot name the same relation in more than one MOVE clause
of a single transfer definition.
The move-relations-rollup-clause has the following
characteristics and limitations:
o All fields in each move-relations-rollup-clause must reside in
the same relation.
o You cannot name the same relation in more than one MOVE clause
of a single transfer definition.
o For each relation of a move-relations-rollup-clause that you
enter, you can supply a target relation specification in the
form of an INTO RELATION clause. You can create one or many
relations in the target database from several source database
relations by renaming the target relations in the transfer
definition.
o You cannot specify MOVE RELATIONS ALL or SELECT FIELDS ALL in
a move-relations-rollup-clause. When you specify these clauses
in the DEFINE TRANSFER statement, the transfer will fail at
the time of definition.
The format of record selection expressions (RSE) that you can
include in a transfer definition for extraction and extraction
rollup transfers is more limited than the RSE allowed by RDO. You
cannot include the following expressions and clauses in the RSE
of the MOVE clause of the DEFINE TRANSFER statement:
o CROSS clause
o ANY operator
o UNIQUE operator
o Host variable
o Statistical expressions
o FIRST FROM expression
o Database key values
o Segmented string expressions
You can specify FIRST clauses, REDUCED clauses, and SORTED BY
clauses in the RSE of both extraction and extraction rollup
transfers. You can achieve the effect of a CROSS clause in an
extraction or an extraction rollup transfer by transferring a
relation, that is itself a view, defined in the source database
as a cross of two or more relations.
The next example shows an extraction transfer definition that
specifies the FIRST, REDUCED, and SORTED BY clauses in the RSE.
The transfer also achieves the capability of a CROSS clause by
moving a view, CURRENT_SALARY. In the source database, CURRENT_
SALARY is a cross of the EMPLOYEES, SALARY_HISTORY, and JOB_
HISTORY relations.
RDO> INVOKE DATABASE FILENAME PERSONNEL
RDO> DEFINE TRANSFER SALARY_HISTORY EXTRACTION
cont> TO NEWNODE::NEWDISK:[NEWDIR]EMP_SALARY
cont> MOVE RELATION FIRST 1000 E IN EMPLOYEES
cont> REDUCED TO E.LAST_NAME
cont> SORTED BY ASCENDING E.LAST_NAME
cont> SELECT FIELDS ALL;
cont> MOVE RELATION C IN CURRENT_SALARY SELECT FIELDS ALL
cont> LOG IS FIRSTDISK:[FIRSTDIR]EMP_SALARY.LOG
cont> END.
Because you cannot use certain expressions to identify required
records, the resulting groups of records transferred to the
extraction database might be larger than the number of extracted
records users will actually use. However, local users on
the target node can then include precise RSEs accessing the
extraction database.
The format of an RSE that you can include in the transfer
definition for replication transfers is more limited than the
RSE allowed by RDO. You cannot include the following forms of
expressions or clauses in the RSE of the MOVE clause of the
DEFINE TRANSFER statement:
o FIRST clause
o CROSS clause
o REDUCED clause
o SORTED BY clause
o ANY operator
o UNIQUE operator
o Host variable
o Statistical expressions
o FIRST FROM expression
o Database key values
o Segmented string expression
Because you cannot use certain expressions to identify required
records, the resulting groups of records transferred to the
replication database might be larger than the number of records
users will actually use. However, local users on the target node
can then include precise record selection expressions when using
RDO to access the replication database.
If a transfer fails during execution, the transfer will begin
again at the next scheduled retry time if the failure results
from a nonfatal error.
This next transfer will start from the beginning to ensure
consistency with any updates that might have been made to the
source database.
Replication Option transfers only definitions for the database,
fields, and relations specified in the transfer definition. If
the source database includes additional database entities such
as indexes, constraints, or access control lists, these are not
transferred to the target database. You must either directly
access the individual target database and explicitly define these
entities or run command procedures to define the entities after
the transfer executes.
When relations specified in the transfer definition are created
in the target database, they are given the access control lists
(ACLs) that have the Oracle Rdb default values. You can change the
ACLs in the target database after it has been created.
Replication Option does not support SQL ANSI-style privileges.
Target databases that Replication Option creates use the
default Oracle Rdb ACL-style privileges. SQL ANSI-style privileges
assigned to a source database are not copied to or preserved on
target databases during transfers.
In a transfer definition, you can use logical symbol names to
name the source database file, the target database file, the
copy process log file, and the prologue and the epilogue command
procedure files. However, Replication Option treats these file
names differently:
o Source database file logical names
If the source file name is a logical symbol that translates
to a standard OpenVMS file name specification, Replication
Option performs the logical name translation. The
SHOW TRANSFER DEFINITION statement shows the source file
name in its translated form. The logical symbol can also
translate into strings that, in turn, contain logical symbols.
As long as the resulting string looks like a OpenVMS file
specification and the logical symbol is not a concealed device
name, the translation process is repeated.
If the logical symbol translates into an Rdb Transparent Gateway
access string (for example, /TYPE=VIDA/FILE=ACCESS_FILE/...),
Replication Option does no further translations. Even if
the VIDA name string contains logical symbol references,
these references are not translated into OpenVMS file
specifications. You can use a logical name in place of the
string to identify an Rdb Transparent Gateway database.
o Target database file logical name
If the target database name is a logical name, it is not
translated by Replication Option when it is stored in the
transfer definition.
o Copy process log file logical name
Replication Option translates the log file logical name in
the same way as source file logical names, with the following
exceptions:
o The log file specification is translated in RDO when the
DEFINE TRANSFER statement is executed.
o These log file names must be standard OpenVMS file
specifications. Node names or version numbers are not
allowed.
o Prologue and epilogue command procedure file logical names
Replication Option translates the prologue and epilogue file
logical names in the same way as the source file logical name,
with the following exceptions:
o The prologue and epilogue file specifications are
translated in RDO when the DEFINE TRANSFER statement is
executed.
o The log file names must be standard OpenVMS file
specifications. Node names and version numbers are
allowed. Replication Option expects node names in file
specifications to be from one to six characters long.
DECnet/OSI permits node names to be much longer than
this. In order to use Replication Option in a DECnet/OSI
environment, you must define and use short synonyms for
the long node names. Node name synonyms can be registered
either in a local or distributed name service database. For
details on establishing node name synonyms, refer to the
documentation for DECnet/OSI.
Prior to Rdb/VMS Version 3.1, data values for text fields were
sorted in ascending or descending order based on the ASCII
character set. With Rdb/VMS Version 3.1 and higher (and Oracle Rdb
Version 5.0 and higher), you can create databases that specify
different sort sequences on a field-by-field basis. You can
specify the default for the database as a whole. Replication Option
has not enhanced transfer definitions to handle collation
sequences in any way. In addition, target databases created by
Replication Option do not have the collation sequence attributes
defined. Sorting in a target database remains ASCII-based.
Currently, there is no way that users can transfer default
collation sequences for fields or databases.
In an extraction transfer, you can change table definitions
in the source database or definitions of columns on which the
transferred tables are based. However, those changes are not
reflected in the transfer definition.
In replication transfers, you can make such changes until the
initial transfer begins. Thereafter, any attempts to change
or delete definitions for tables or columns in the replication
transfer are not allowed, with the exception of the following
four column attributes; these attributes can be modified even
after the initial transfer begins:
o Edit string
o Default value for DATATRIEVE
o Query name for DATATRIEVE
o Query header
However, note that if you do change the attributes listed in a
source column, a comparable change is not made automatically to
the target database column. If you want that to happen, you must
make the change in both the source and the target databases.
In both extraction and replication transfers, if you make changes
that cause the source tables or columns to be incompatible
with the transfer definitions, Replication Option detects these
differences at the time of transfer execution. The transfer
fails, the transfer status reflects the failure, and the transfer
is suspended.
However, with extractions or initial replications, the copy
process does not detect changes to the data type of a field.
For example, you can change a field from the data type CHAR to
the data type INTEGER without causing a failure.