ALTER REPLICATION
ADD REPLICATE
Adds an
additional remote table to an existing table replication.
SYNTAX
| replication_name |
Name
of the synchronous table replication you want to add an additional
remote table to. |
| local_table_name |
Name
of the local table the existing replication was created on. |
| remote_table_name
|
Name
of the table in the remote database you want to replicate to. |
| column_name |
Name
of a column in the remote table you want to replicate to. |
DESCRIPTION
The ALTER
REPLICATION ADD REPLICATE command adds an additional remote table to an
existing synchronous table replication. You can add as many additional
remote tables to a synchronous replication as you wish. To execute the
ALTER REPLICATION ADD REPLICATE command you must be the table owner, or
have DBA or SYSADM security privileges.
A table
replication creates a full or partial copy of a table in a remote location.
This allows users in remote locations to work with a local copy of data.
The local copy remains synchronized with the databases in other locations.
This way each database can service data requests immediately and efficiently,
without having to go to another machine over a slower network connection.
This is not the same as backing up the database to a remote location,
since the synchronization is done on a transaction-by-transaction basis
by the DBMS itself, without any intervention from users.
There are
two primary types of table replication: synchronous and asynchronous.
Synchronous table replication modifies the remote table at the same time
it modifies the local table, while asynchronous table replication stores
changes to the local table and modifies the remote table based on a schedule.
The ALTER REPLICATION ADD REPLICATE command modifies synchronous table
replications.
Synchronous
table replication in DBMaker uses a global transaction model, in which
the replication of data to the remote table is treated as an integral
part of the local transaction. (A transaction is traditionally defined
as a logical unit of work, or one or more operations on a database that
must be completed together to leave the database in a consistent state.
Transactions
are self-contained an must either complete and change the data, or fail
and leave the data unchanged.) This means that if the replication of data
to the remote database fails, the transaction on the local table will
also fail.
When you
modify a synchronous table replication you must specify the replication
name, the local table name, and the names of the additional remote tables
you want to replicate to. Both the local table and the remote tables must
already exist in their respective databases. DBMaker will automatically
drop any replications you create on a table when you drop the table.
DBMaker
will replicate the entire table unless you specify the individual columns
you want to replicate using a column list. When you replicate an entire
table without providing a column list, the columns in the local table
and corresponding columns in the remote table must have the same name
and data type. If the column names in the local and remote tables are
different, you can provide a column list for the remote table. Columns
in the local table (from left to right) will replicate to the corresponding
columns named in the column list for the remote table. You can explicitly
specify which columns in the local table correspond to columns in the
remote table by providing a column list for both the local and remote
tables. In all cases, you must include the primary key columns in the
replication, and the number and data type of primary key columns in both
tables must match.
Unlike most
database objects, DBMaker does not identify replications using fully qualified
names (a combination of owner and object names), but associates them with
tables instead. For this reason all replication names on the same table
must be unique. The replication operates with the same security and object
privileges as the owner of the trigger table, unless the remote table
is specified using links. In this case, the replication operates with
the same security and object privileges as the link.
The CLEAR
DATA/FLUSH DATA/CLEAR AND FLUSH DATA keywords are optional. These keywords
specify the operations that will take place when you create a replication.
The CLEAR DATA keywords will delete all data from the remote table when
you create the replication. The FLUSH DATA keywords will copy all data
that matches a search condition into the remote table. The CLEAR AND FLUSH
DATA keywords will clear all data from the remote table, and then copy
all data that matches a search condition into the remote table. If you
do not specify an action, no action will take place.
EXAMPLES
The following
example modifies an existing replication named EmpRep created on the local
Employees table. The remote database is identified by a database configuration
section named Div1Office in the local dmconfig.ini configuration file.
The remote table is named Div1Emp, and all column names and data types
in both tables are the same.
ALTER REPLICATION EmpRep ON Employees ADD REPLICATE TO
Div1Office:Div1Emp
|
The following
example is similar to the above example, but all data in the remote table
is deleted and then any existing data in the local table is sent to the
remote table.
ALTER REPLICATION EmpRep ON Employees ADD REPLICATE TO
Div1Office:Div1Emp CLEAR AND FLUSH DATA
|
The following
example is similar to the above example, but adds replication to the Div2Emp
table in the remote Div2Office database, and the Div3Emp table in the
remote Div3Office database. Both remote databases have a database configuration
section with the same name as the database in the local dmconfig.ini configuration
file.
ALTER REPLICATION EmpRep ON Employees ADD REPLICATE TO
Div2Office:Div2Emp CLEAR AND FLUSH DATA
Div3Office:Div3Emp CLEAR AND FLUSH DATA
|
RELATED COMMANDS
<
ALTER PASSWORD | Contents
| ALTER REPLICATION DROP
REPLICATE >
|
