>>-cdr define replicate--+-------------------------+------------>
                         |                    (1)  |
                         '-| Connect Option |------'
 
>--+-----------------------------------+------------------------>
   |                              (2)  |
   '-| Master Replicate Options |------'
 
                        (3)
>--| Conflict Options |-------+------------------------+-------->
                              |                   (4)  |
                              '-| Scope Options |------'
 
>--+----------------------------+------------------------------->
   |                       (5)  |
   '-| Frequency Options |------'
 
>--+--------------------------+--------------------------------->
   |                     (6)  |
   '-| Special Options |------'
 
>--+-replicate-------------------------+------------------------>
   |                              (7)  |
   '-| Shadow Replicate Options |------'
 
   .---------------------------.
   V                           |
>----+-----------------------+-+-------------------------------><
     '-participant--modifier-'
 

1. See page Connect Option.
2. See page Master Replicate Options.
3. See page Conflict Options.
4. See page Scope Options.
5. See page Frequency Options.
6. See page Special Options.
7. See page Shadow Replicate Options.

To be useful, a replicate must include at least two participants. You can define a replicate that has one or no participant, but before you can use that replicate, you must use cdr change replicate to add more participants. You cannot start and stop replicates that have no participants.

When you define a replicate, the replicate does not begin until you explicitly change its state to active. For more information, see cdr start replicate.

The master replicate options specify whether Enterprise Replication defines the replicate as a master replicate. A master replicate uses saved dictionary information about the attributes of replicated columns to verify that participants conform to the specified schema. You must specify at least one participant when creating a master replicate. All participants specified are verified when the cdr define replicate or cdr change replicate command is executed. If any participant does not conform to the master definition, then the command fails and that local participant is disabled. If a participant you specify does not contain the master replicate table, Enterprise Replication automatically creates the table on the participant based on the master replicate dictionary information. All database servers containing master replicates must be able to establish a direct connection with the master replicate database server. For more information, see Defining Master Replicates.

Master Replicate Options:
 
|-- --master=server--+----------+--+----------------+----------->
                     '- --empty-'  |          .-y-. |
                                   '- --name=-+-n-+-'
 
>--+---------------+--------------------------------------------|
   +- --verify-----+
   '- --autocreate-'
 

The following table describes the master replicate options.

The --conflict options specify how Enterprise Replication should resolve conflicts with data arriving at the database server.

For more information, see Conflict Resolution.

Conflict Options:
 
|-- --conflict=------------------------------------------------->
 
>--+-always-----------------------------------------+-----------|
   +-ignore-----------------------------------------+
   +-SPL_routine--+-------------+-------------------+
   |              '- --optimize-'                   |
   '-timestamp--+---------------------------------+-'
                '-,--SPL_routine--+-------------+-'
                                  '- --optimize-'
 

The following table describes the conflict options.

The --scope options specify the scope of Enterprise Replication conflict resolution.

Scope Options:
 
|-- --scope=--+-row---------+-----------------------------------|
              '-transaction-'
 

The following table describes the --scope option.

Special Options:
 
   .-------------------------.
   V                         |
|----+---------------------+-+----------------------------------|
     +- --ats--------------+
     +- --ris--------------+
     +- --floatieee--------+
     +- --floatcanon-------+
     +- --firetrigger------+
     +- --fullrow--+-y-+---+
     |             '-n-'   |
     '- --ignoredel--+-y-+-'
                     '-n-'
 

The following table describes the special options to cdr define replicate.

A shadow replicate is a copy of an existing, or primary, replicate. You must create a shadow replicate to perform a manual remastering of a replicate that was defined with the -n option. After creating the shadow replicate, the next step in manual remastering is to switch the primary replicate and the shadow replicate using the cdr swap shadow command.

Shadow Replicate Options:
 
|--+-------------------------------------------------+----------|
   '- --mirrors--primary_replicate--shadow_replicate-'
 

The following table describes the shadow replicate option to cdr define replicate.

The following example illustrates the use of cdr define replicate:

cdr define repl --conflict=timestamp,sp1 \

--scope=tran --ats --fullrow n --floatieee newrepl \

"db1@iowa:antonio.table1" "select * from table1" \

"db2@utah:carlo.table2" "select * from table2"

Line 1 of the example specifies a primary conflict-resolution rule of timestamp. If the primary rule fails, the SPL routine sp1 will be invoked to resolve the conflict. Because no database server is specified here (or on any later line), the command connects to the database server named in the INFORMIXSERVER environment variable.

Line 2 specifies that the replicate has a transaction scope for conflict-resolution scope and enables aborted transaction spooling. Enterprise Replication will only replicate the rows that changed and uses the IEEE floating point format to send floating-point numbers across dissimilar platforms. The final item specifies the name of the replicate, newrepl.

Line 3 defines the first participant, "db1@iowa:antonio.table1", with the select statement "select * from table1".

Line 4 defines a second participant, "db2@utah:carlo.table2", with the select statement "select * from table2".

The next example is the same as the preceding example with the following exceptions:

• Line 1 instructs Enterprise Replication to use the global catalog on database server ohio.
• Line 2 specifies that the data should be replicated every five hours.

cdr def repl -c ohio -C timestamp,sp1 \

-S tran -A -e 5:00 -I newrepl \

"db1@iowa:antonio.table1" "select * from table1" \

"db2@utah:carlo.table2" "select * from table2"

The following example illustrates creating a master replicate:

cdr def repl -c iowa -M iowa \

-C timestamp -S tran -D y newrepl \

"db1@iowa:antonio.table1" "select * from table1"

Line 1 instructs Enterprise Replication to create a master replicate based on the replicate information from the database server iowa. Line 2 specifies the conflict and scope options, that delete operations are ignored, and that the name of the replicate is newrepl. Line 3 specifies the table and columns included in the master replicate.

The next example is the same as the previous example except that it specifies a second participant in Line 4. The second participant (utah) does not have the table table1 specified in its participant and modifier syntax; the execution of the cdr define replicate command creates table1 on the utah server.

cdr def repl -c iowa -M iowa \

-C timestamp -S tran -D y newrepl \

"db1@iowa:antonio.table1" "select * from table1 \

"db2@utah:carlo.table1" "select * from table1"

• cdr change replicate
• cdr delete replicate
• cdr list replicate
• cdr modify replicate
• cdr resume replicate
• cdr start replicate
• cdr stop replicate
• cdr suspend replicate
• cdr swap shadow