create subscription

Creates and initializes a subscription and materializes subscription data. The subscription may be for a database replication definition, table replication definition, function replication definition, or publication. You can create a database subscription with materialization of the whole database or a subset of the tables. The command supports "and", "or", and "in value list" operators in subscription where clauses. The limitation for this support is that each sub-clause in "and" and "or" must conform and adhere to current SAP Replication Server standards.

Syntax

To create a database subscription:

create subscription <subname>
for database replication definition <repdefname>
with primary at <pdsname.pdbname>
with replicate at <rdsname.rdbname>
{with materialization 
[init replicate table with {create | create_or_truncate | truncate | recreate} 
[date time]
[user <username> password <password>]]
| without materialization}
[subscribe to truncate table]

To create a non-database subscription:

create subscription <subname> 
for {table_repdef | func_repdef | publication pub}
[with primary at <pdsname.pdbname>]
with replicate at <rdsname.rdbname>
[where 
      {{column_name | @param_name}
      {< | > | >= | <= | = | &} value
      [and {column_name | @param_name}
      {< | > | >= | <= | = | &} value]...
      [or where { column_name | @param_name }
      {< | > | >= | <= | = | &} value
      [and {column_name |@param_name}
      {< | > | >= | <= | = | &} value]...]} |
      {{column_name | @param_name}
      in (value1,value2,value3...)
      [and {column_name | @param_name}
      in (value1,value2,value3...)]...
      [or where { column_name | @param_name }
      in (value1,value2, value3...)
      [and {column_name |@param_name}
      in(value1,value2,value3...)...]...]}]
[without holdlock [direct_load [init replicate table with {create |
      create_or_truncate | truncate | recreate}]
      [user username password pass][num_of_selects selects]
[hold_resource_on_error]]| incrementally | without materialization]
[subscribe to truncate table]
[for new articles]

Parameters

sub_name

The name of the subscription, which must conform to the rules for naming identifiers. The subscription name must be unique for the replication definition, where applicable, and for the replicate data server and database.

for table_rep_def

Specifies the table replication definition the subscription is for.

for function_rep_def

Specifies the name of the function replication definition the subscription is for.

for publication pub_name

Specifies the publication the subscription is for.

for database replication definition db_repdef

Specifies the database replication definition the subscription is for.

with primary at data_server.database

Specifies the location of the primary data. If the primary database is part of a warm standby application that uses logical connections, <data_server.database> is the name of the logical data server and database. You can also specify an alternate primary connection name in the clause if you are configuring a multi-path replication system.

with replicate at data_server.database

Specifies the location of the replicate data. If the replicate database is part of a warm standby application, <data_server.database> is the name of the logical data server and database. You can also specify an alternate replicate connection name in the clause if you are configuring a multi-path replication system. For table subscriptions created with the direct_load option, this is the name of the physical data server and database name; logical or alternate connection names are not allowed.

where

Sets criteria for the column or parameter values that are to be replicated via the subscription. If you omit the where clause, all rows or parameters are replicated.

You can include a where clause in a subscription for a table or function replication definition. You cannot include a where clause in a database or publication subscription.

A where clause is composed of one or more simple comparisons, in which a searchable column or searchable parameter from the replication definition is compared to a literal value using one of these relational operators: <, >, <=, >=, =, or &. (The & operator is supported only for <rs_address> columns or parameters.) You can join comparisons using the keyword and and or. You can group all the rules of one column to a in value list. Example 13 illustrates this scenario.

Column or parameter names used in the expression must be included in the searchable columns list of the table replication definition or the searchable parameters list of the function replication definition.

Java columns cannot be evaluated in subscription expressions. Thus, you cannot include a Java column of type <rawobject> or <rawobject in row> in a where clause.

The maximum size of a where clause in a subscription is 255 characters.

Note

You cannot convert binaries with less than seven bytes into integers. Workarounds include using zeros to pad binary values up to eight bytes, or using integer values instead of binary values.

column_name

A column name from the primary table, for a subscription to a table replication definition.

@param_name

A parameter name from a replicated stored procedure, for a subscription to a function replication definition.

value

A value for a specified column or parameter. See Datatypes for entry formats for values for different datatypes.

Column or parameter names used in the expression must be included in the searchable columns or searchable parameters list of the replication definition.

without holdlock

Selects data from the primary database without a holdlock, for non-atomic materialization. The rows are applied at the replicate database in increments of 1000-row inserts per transaction. For subscriptions created with the direct_load option, the number of rows applied is determined by the mat_load_tran_size configuration parameter. See “Nonatomic Materialization” for more information.

init replicate table with create

Creates the table at the replicate database. If the table already exists, the materialization fails.

init replicate table with create_or_truncate

Creates the table at the replicate database. If the table already exists, Replication Server uses the existing table after truncation.

init replicate table with truncate

Truncates the table at the replicate database. If the table does not exist, materialization fails.

init replicate table with recreate

Drops the table at the replicate database and recreates the table.

Note Materialization does not fail if the replicate table does not already exists.

incrementally

Initializes the subscription and apply subscription data in increments of 1000-row inserts per transaction. A holdlock is used on the primary database, for atomic materialization.

without materialization

Does not materialize data for the subscription. Use this option when there is no activity at the primary database and the data already exists in the replicate database. Or, use this option when you have suspended activity in the primary database and manually transferred the data to the replicate database. Database subscriptions must include this option.

subscribe to truncate table

For a subscription to a table replication definition, a database replication definition, or to a publication, enables replication of the truncate table command to the subscribing replicate database.

You must set this option the same as it is set for any existing subscriptions that replicate data into the same replicate table for a particular database. Otherwise, the new subscription is rejected.

for new articles

Refreshes an existing subscription. Instructs Replication Server to check the subscription against the publication and then to create subscriptions against unsubscribed articles.

direct_load

Enables direct load materialization.

When this option is used, no other subscription can be created at the same time for the same replicate table. You can only use this option against a physical database connection, not an alternate or logical connection.

This option is available only if the replicate SAP Replication Server site version and route version to its primary SAP Replication Server are 1571100 or later.

user <username> password <pass>

The user ID and password used in direct load materialization to connect to the primary Adaptive Server database or Replication Agent and select from the primary table.

<num_of_selects> selects

Enables multiple select threads to improve the materialization performance for subscriptions created with direct_load option. The default value is 1, and valid values are 1 – 10. You can use this option only with the direct_load option, and it is available only when the primary database is either DB2 UDB 9.7 and later, or Oracle, and when the function string rs_select is not customized. This number is adjusted down to 1 otherwise, or when there are not many rows in the primary table.

hold_resource_on_error

Holds the resource for the subscription if the subscription created with direct load materialization results in an error.The default is not hold resource when a subscription created with the direct_load option results in an error.

Examples

Example 1

Creates a subscription named <titles_sub>. It specifies that rows from the <titles >table with columns of the type “business” are to be replicated in the <titles> table in the <pubs2> database of the data server named SYDNEY_DS:

create subscription titles_sub
 for titles_rep
 with replicate at SYDNEY_DS.pubs2
 where type = 'business’

Example 2

Creates a subscription named <titles_sub> that includes rows from the <titles> table with prices that are greater than or equal to $10.00:

create subscription titles_sub
 for titles_rep
 with replicate at SYDNEY_DS.pubs2
 where price >= $10.00

Example 3

Creates a subscription named <myproc_sub> for the function replication definition <myproc_rep>. In order to use this command to create a subscription for a function replication definition, data must already exist at the replicate database, and you must use the without materialization clause:

create subscription myproc_sub
 for myproc_rep
 with replicate at SYDNEY_DS.pubs2
 without materialization

Example 4

Creates a subscription named <pubs2_sub> for the publication <pubs2_pub>:

create subscription pubs2_sub
 for publication pubs2_pub
 with primary at TOKYO_DS.pubs2
 with replicate at SYDNEY_DS.pubs2

Example 5

Creates a database subscription <pubs2_sub> for the database replication definition <pubs2_rep>:

create subscription pubs2_sub
 for database replication definition pubs2_rep
   with primary at NEWYORK_DS.pubs2
   with replicate at TOKYO_DS.pubs2
 without materialization
 subscribe to truncate table

Example 6

Creates the sub_conn2 subscription for the repdef_conn2 replication definition on the NY_DS.rdb_conn2 alternate replicate connection:

create subscription sub_conn2 for repdef_conn2
with replicate at NY_DS.rdb_conn2
without materialization
go

Example 7

Creates the sub_conn2 subscription against the repdef_conn2 replication definition on the LON_DS.pdb_conn2 alternate primary connection to the LON_DS primary data server where NY_DS.rdb is the default replicate connection:

create subscription sub_conn2 for repdef_conn2
with primary at LON_DS.pdb_conn2
with replicate at NY_DS.rdb
without materialization
go

Example 8

Creates a subscription with the direct load option named <titles_sub> that includes rows from the <titles> table with prices that are greater than or equal to $10.00:

create subscription titles_sub
 for titles_rep
 with replicate at SYDNEY_DS.pubs2
 where price >= $10.00
 without holdlock
 direct_load

Since no user ID and password are provided explicitly, the user ID and password that were used to create the subscription are usedto login to the primary database or Replication Agent to select data from the primary table. When the primary database is not Adaptive Server, Replication Server assumes that the user ID is the Replication Agent administrator user.

Example 9

Creates a subscription with the direct load option named <titles_sub> that includes rows from the <titles> table with sales greater than 5,000 copies:

create subscription titles_sub
 for titles_rep
 with replicate at SYDNEY_DS.pubs2
 where total_sales > 5000
 without holdlock
 direct_load
 user pubs2_owner password pubs2_owner_pwd

Replication Server uses the pubs2_owner user ID and the pubs2_owner_pwd password to log in to the Adaptive Server primary database or Replication Agent and issue a select on the primary database table.

Example 10

Creates a subscription with the direct_load option named authors_sub with at most 3 select threads:

create subscription authors_sub for authors_repdef
       with replicate at ost_replnxb10_01.rdb1
      without holdlock direct_load 3 selects

Since no user ID and password are provided explicitly, the user ID and password that were used to create the subscription are used to login to the primary database or Replication Agent to select data from the primary table. When the primary database is not Adaptive Server, Replication Server assumes that the user ID is the Replication Agent administrator user.

Example 11

Using the in value list operator:

create subscription sub_name
for {table_repdef | func_repdef | {publication pub |
database replication definition db_repdef}
with primary at server_name.db}
with replicate at data_server.database
[where {column_name | @param_name}
in {value1,value2,value3...}
[and {column_name | @param_name}
in {value1,value2,value3...}]...
[or where { column_name | @param_name }
in {value1,value2, value3...}
[and {column_name |@param_name}
in{value1,value2,value3...]...]...]

Example 12

Create a subscription with the "or" keyword in the "where" clause:

create subscription tb_name_demo
for tb_name_repdefdemo
with replicate at rqa10.tdb2
where col1 > 20
and col1 < 100
or where col2 = 'charvalue0'
or where col3 = 'varcharvalue0'

Example 13

Create a subscription with the "in value list" keyword in the "where" clause:

create subscription tb_name_subdemo
for tb_name_repdefdemo
with replicate at rqa10.tdb2
where col2 in ('charvalue0','charvalue2', 'charvalue3','charvalue4')
or where col3 in ('varcharvalue0')

Usage

To subscribe to a function or database replication definition, use create subscription with the without materialization clause, or use define subscription and the other bulk materialization commands.
Execute create subscription at the Replication Server of the database where the replicated data will be stored.
See the Replication Server Administration Guide Volume 1 for more information about subscriptions and the role they play in replication.
Starting from Replication Server 15.5, if you change a replication definition that has table subscriptions, you do not have to drop and re-create the table subscriptions.
You can create multiple replication definitions for the same primary table or database. You cannot subscribe to more than one replication definition for the same replicate table or database, although you can subscribe to the same replication definition more than once.
For multi-path replication, since all primary connections between a primary database and a Replication Server share all replication definitions, you must specify in the subscription which primary connection is the data source and which replicate connection is the replication target. See Replication Server Administration Guide Volume 2 > Performance Tuning > Multi-Path Replication.
Support for subscription materialization of LOB compressed data depends on how you specify the column datatype in the replication definition and on the version of Replication Server. See Subscription Materialization of LOB Compressed Data in the Replication Server Administration Guide Volume 1.
If you are using quoted identifiers with a custom function string that includes a quoted constant, create subscription without a quoted constant or without materialization clause. Otherwise, during subscription materialization the quoted constant causes a query failure. The replicate data server identifies the quoted constant as a column instead of a constant.

Subscribing to Database Replication Definitions

When you create a database subscription, you cannot use the where clause to limit data subscription. All data is subscribed.
With database subscriptions, you can use only the no materialization or bulk materialization methods. Use define subscription to use dump and load or other bulk materialization method. Use create subscription to use the no materialization method.
You cannot subscribe to more than one database replication definition from the same origin.
If your replicate Replication Server is at lower version than your primary Replication Server, you cannot create a database subscription at the replicate Replication Server for a primary database controlled by the primary Replication Server.
To successfully create a table replication definition for a primary database that is subscribed by a database subscription, the replicate Replication Server must be at the same or higher version as the table replication definition.

Subscribing to Publications

When a publication is valid, you can create a subscription for the publication in order to begin replication to a replicate database. All forms of subscription materialization are supported.
When you create a publication subscription, Replication Server creates a separate underlying subscription for each article that the publication contains. Each article subscription uses the name of the parent publication subscription.
- When you use atomic or non-atomic materialization, article subscriptions are materialized one at a time in the order that the articles were added to the publication.
- When you use create subscription with the without materialization clause, all article subscriptions are activated and validated at the same time.
A subscription to a publication cannot include a where clause. Instead, you can customize replication to replicate sites by including one or more where clauses in each article the publication contains.

Specifying Columns Subject to HDS Translations

When you create a subscription that includes a where clause, make sure that the value in the where clause comparison is in the declared datatype format.
Subscriptions that specify columns subject to class- or column-level translations in the where clause cannot be dematerialized automatically. You must use either the bulk or the no-materialization method.

Replicating Truncate Table

When you create the first subscription, you can either include or not include the subscribe to truncate table option. Each subsequent subscription that replicates into the same table must follow the example of the first subscription. Otherwise, the subscription is rejected when you try to create it.
You can change the current "subscribe to truncate table" status of a particular replicate table by executing sysadmin apply_truncate_table

Requirements for Executing create subscription

In addition to the permissions listed below, make sure that these requirements are met before you execute create subscription.
For a subscription to a table replication definition:
- A replication definition exists for the primary table you are replicating, and the table is marked for replication with sp_setreptable.
- If you subscribe to tables marked using sp_reptostandby, you must configure the primary database connection using the rep_as_standby configuration parameter and configure Replication Agent using send_warm_standby_exacts.
- Tables referenced in the replication definition exist in both the primary and the replicate database. Each table has the columns and datatypes defined in the replication definition.
  
  This table is visible to the user creating the subscription and to the user maintaining it. The easiest way to achieve this is to have the Database Owner creates the table.
For a subscription to a function replication definition:
- A replication definition exists for the stored procedure you are replicating, and the stored procedure is marked for replication with sp_setrepproc.
- Stored procedures referenced in the function replication definition exist in both the primary and replicate database. Each stored procedure has the parameters and datatypes defined in the function replication definition.
For a subscription to a publication:
A publication exists that contains articles for the primary tables or stored procedure you are replicating. The articles specify replication definitions that meet the requirements described above.
The publication is valid.

Requirements for Warm Standby Applications

These requirements apply when you create subscriptions in warm standby applications:
- If the destination database is part of a warm standby application, the table must exist in both the active and standby databases. Both tables must be marked for replication using sp_setreptable or sp_reptostandby.
- For a logical primary database, you cannot create a subscription while Replication Server is in the process of adding a standby database.
- You cannot create table subscriptions against warm standby connections with the direct_load option.

Requirements for Tables with the Same Name

If a primary Adaptive Server database contains a replicated table and another table that has the same name, the owner of the second (unreplicated) table cannot create a subscription to the replicated table without using custom rs_select or rs_select_with_lock function strings. For example:
- If there is a replication definition for a primary table named <db.dbo.table1>, and
- Database user “jane” owns a table named <db.jane.table1>, then
- Jane cannot create a subscription to the replication definition for <db.dbo.table1> using the default function strings.

Atomic Materialization

The default method for materializing subscriptions with this command is atomic materialization. Atomic materialization locks the primary table and copies subscription data through the network in a single atomic operation.
During atomic materialization, no rows appear at the replicate database until the select transaction has been completed in the primary database. If the subscription specifies a large number of rows, the select transaction can run for a long time, causing a delay at the replicate site.

Requirements for Using Atomic Materialization

If you plan to use the atomic method of subscription materialization:
- You or the Database Owner must own the primary table, or you must use user-defined function strings for select operations at the primary database.
- The Database Owner or the maintenance user must own the replicate table, or you must use user-defined function strings for select operations at the replicate database. If the owner of the replicate table is different from the owner of the primary table, you must create a unique function string by using a distinct function-string class.The primary database must be an Adaptive Server database.

Using the Without Holdlock or Incrementally Option

The without holdlock or incrementally options are alternatives to the default atomic method of subscription materialization. When you specify these options, Replication Server applies the rows in batches, so that data appears at the replicate database a batch at a time.

As a result, during materialization, queries at the replicate database may return incomplete data for the subscription. This temporary condition ends when check subscription indicates the subscription is valid.

The Incrementally Option

The incrementally option is a variation of atomic materialization. Use this option for large subscriptions to avoid a long-running transaction at the replicate database. The subscription data is not applied atomically at the replicate database, so the data is available; however, it is incomplete until materialization has completed and the subscription is validated.
When incrementally is used, select is performed with a holdlock to maintain serial consistency with the primary database. The replicate table passes through states that occurred previously at the primary database.

In all cases, replicate data is consistent with the primary database by the time materialization completes and check subscription indicates that the subscription is valid.

Nonatomic Materialization

The without holdlock option uses non-atomic materialization. When this option is specified, materialization rows are selected from the primary database without a holdlock. This can introduce inconsistency if rows are updated at the primary database after the select. To correct inconsistencies, use set autocorrection on when using without holdlock.
When data already exists at the replicate database, you can use atomic or non-atomic materialization instead of bulk materialization.

Requirements for Using Nonatomic Materialization

If you plan to use non-atomic method of subscription materialization:
- Do not use without holdlock if you update data by distributing applied functions from the primary database or if you update the data with commutative functions. For example, if a stored procedure updates a row by incrementing the previous value of a column, the value may be incorrect when materialization has completed.
- For non-atomic subscriptions, if a non-atomic subscription is materializing when switch active executes, it is marked “SUSPECT.

Note

If you are using create subscription with either atomic or non-atomic materialization methods and you have quoted identifiers in your replication definition, then you must alter your primary connection to allow the use of quoted identifiers.

Direct Load Materialization

The direct_load option can only be used to materialize data into HANA DB.
To use direct_load, you must connect from Replication Server to a non-Adaptive Server primary database using the appropriate connection profile: rs_rs_to_msss_ra, rs_rs_to_oracle_ra, or rs_rs_to_udb_ra.
When the direct_load option is used, no other subscription can be created at the same time for the same replicate table.
Unlike other automatic materialization methods, data selected from the primary table is loaded directly to the replicate database—no materialization queue is used—as soon as it is returned from the select command.
The direct_load option is for subscriptions to table replication definitions only and is used with without holdlock. It cannot be used with without materialization or incrementally.
A catch-up queue holds DML operations made to a primary table for which a subscription materialization is in progress, preventing the need to suspend replication for other tables that are already being replicated. After the data selected from the primary table is applied to the replicate table, the DML operations in the catch-up queue are applied to the replicate table. Autocorrection is applied between subscription-activation and subscription-validation markers to operations in the catch-up queue.
Note
- When DML operations in a catch-up queue are applied to the replicate table, each insert operation is converted into a delete followed by an insert. Materialization fails when an update changes the primary key.
- For direct load materialization, Replication Server selects rows from the primary table without holdlock. Thus if a row is being deleted and inserted multiple times while the selection is going on, multiple rows with the same primary key could be selected. Inserting these rows to the replicate table would cause unique index violation if there is a unique index on the replicate table. To avoid the unique index violation error, you can drop the unique index at the replicate and recreate the unique index after the subscription becomes valid. The temporary inconsistency would be resolved during the subscription catch-up time.
The user and password options are used only with direct_load. The user ID must have permission to log in to the primary Adaptive Server database or Replication Agent and must have select permission on the primary database table being materialized. The <username> and <pass> values are used once and not stored in the RSSD.
Note When the primary database is not Adaptive Server, Replication Server may connect to the primary database and perform the select through Replication Agent. In this case, the user ID and password used in the create connection command are those needed to connect to Replication Agent and not those needed to connect to the primary database.
If no value is provided for this option, the user ID and password that were used to create the subscription are used to log on to the primary Adaptive Server database or Replication Agent and select from the primary table.
The <num_of_select> selects option is used only with direct_load to allow multiple select threads for improving materialization performance. 1 is the default and minimum value for this option, and the maximum is 10. Multiple select threads are only supported for IBM DB2 and Oracle primary databases, and when function string rs_select is not customized. This number is adjusted down to 1 otherwise, or when there are not many rows in the primary table.
You cannot use the direct_load option against a logical connection or alternate connection. The primary connection in the replication definition and the replicate connection in the subscription must be physical connections.
If the primary database is not Adaptive Server, and if a subscription is being created without the without materialization option, the direct load option must be used.
The direct_load option is available only if the replicate Replication Server site version and route version are 1571100 or later.
You can use row filtering, name mapping, customized function strings and datatype mapping with subscriptions created using the direct_load option.
The data server name of a primary database connection must exist in the interfaces file of the Replication Server from which create subscription is issued.

No Materialization

The without materialization clause specifies the no-materialization method. It provides an convenient way to create a subscription when the subscription data already exists at the replicate database.

Requirements for No Materialization

The subscription data must already exist at the replicate database.
The primary and replicate database must be in sync.
Activity must be stopped at the primary database so that there are no further updates in the Replication Server stable queue.

Using the rs_address datatype

You can subscribe to replication definitions whose columns or parameters use the special datatype <rs_address>. This datatype allows a unique subscription resolution method, whereby bitmaps of the <rs_address> datatype (based on the underlying <int> datatype) are compared with a bitmask in a subscription where clause. The bitmap comparison tells the primary Replication Server whether or not a replicate site should receive the data in each row.

For <rs_address> columns or parameters only, the bitmap comparison operator & is supported in the where clause, as follows:

where <rs_address_column1>  & <bitmask
>[and <rs_address_column2>  & <bitmask>]
 [and <other_search_conditions>]

Replication Server does not replicate a row if the only changed columns are <rs_address> columns, unless the changed bits indicate that the row should be inserted or deleted at the replicate database.

Because of this filtering, <rs_address> columns in replicate databases may not be identical to the corresponding columns at the primary database. This optimizes applications that use <rs_address> columns to specify the destination replicate databases.

How the rs_address datatype works

Each bit in an <rs_address> column field may represent a category of data, such as inventory or billing. In a subscription bitmask, you set the corresponding bit to “on” (1), for each category of data you want to replicate to the subscribing site.

For example, users at a warehouse site who are interested in inventory data would set the inventory bit to “on” in a subscription bitmap. If the same warehouse users are not interested in billing data, they would set that bit to “off” (0). When a bit is set to “on” in both a subscription bitmask and an <rs_address> column, the row containing the bit is replicated.

32-Bit Limitation of Underlying int datatype for rs_address

Due to the 32-bit limitation of the underlying <int> datatype, you may need to construct primary tables with more than one <rs_address> column. The and keyword allows you to create a single subscription to perform bitmap comparisons on more than one <rs_address> column.

However, to subscribe to a row when one or more bits are set in either of two or more <rs_address> columns, you must create separate subscriptions.

Using 32-Bit Hexadecimal Numbers for rs_address

You can also specify search conditions for non-<rs_address> columns using the and keyword and the comparison operators (other than &) described in the command syntax. If you use and to specify search conditions, subscription data may not be replicated or may migrate out of a subscription, even if <rs_address> bitmap comparisons would otherwise replicate a row.
You can compare <rs_address> columns to 32-bit integer values or 32-bit hexadecimal numbers in the where clause. If you use hexadecimal numbers, pad each number with zeros, as necessary, to create an 8-digit hexadecimal value.

Caution
Be very cautious about comparing <rs_address> columns to hexadecimal numbers in the where clause of a subscription. Hexadecimal values are treated as binary strings by Adaptive Server and Replication Server. Binary strings are converted to integers by copying bytes. The resulting bit pattern may represent different integer values on different platforms.

For example, 0x0000100 represents 65,536 on platforms that consider byte 0 most significant, and represents 256 on platforms that consider byte 0 least significant. Because of these byte-ordering differences, bitmap subscriptions involving hexadecimal numbers may not work in a multi-platform replication system.
See "Datatypes" for more information about the <rs_address> and <int> datatypes. Also, see the Replication Server Administration Guide Volume 1.
Refer to the Adaptive Server Enterprise Reference Manual and the Open Client and Open Server Common Libraries Reference Manual for more information about conversion between datatypes.

Monitoring a Subscription

When Replication Server materializes a subscription, it logs in to the primary data server, using the subscription creator login name, and selects the rows from the primary table. Use check subscription to monitor the progress of the materialization.
create subscription returns a prompt before the data materialization is complete. Materialization is complete when check subscription reports “VALID” at the replicate Replication Server.
If you use create subscription with the with materialization option, before the materialization process begins, SAP Replication Server automatically marks the primary table replicable with owner on. If the table is already marked as replicable with owner on, the materialization continues. If the table is already marked as replicable with owner off, the materialization process stops and reports an error.
To perform database materialization for tables with timestamp columns, enable the send_timestamp_to_standby configuration parameter for the direct load connection to the primary Replication Agent, and for the connection to the replicate database.

Permissions

To execute create subscription, you must have the following login names and permissions:

If you do not use the user <username> password <pass> option, you must use the same login name and password at the replicate Replication Server, primary Replication Server, and primary database.
“create object” or “sa” permission at the replicate Replication Server where you enter this command.
“create object”, “primary subscribe”, or “sa” permission at the primary Replication Server.
select permission on the primary table in the primary Adaptive Server database.
execute permission on the rs_marker stored procedure in the primary Adaptive Server database.
The replicate database maintenance user must have select, insert, update, and delete permissions on the replicate table, and execute permissions for functions used in replication.
The maintenance user of the primary database cannot be used in the user <username> password <pass> option to create subscriptions. Because the maintenance user is ignored by default in replication, SAP recommends that you do not use the maintenance user.
If you specify user <username> password <pass> in the create subscription command with the direct_load option, this name is used to log in to the primary Adaptive Server database or Replication Agent and select from the primary table. If you do not specify <username> in the create subscription command, the name and password you used to log in to Replication Server are used to connect to the primary Adaptive Server database or Replication Agent. Make sure that whatever name is used to log in to the primary Adaptive Server database or Replication Agent has the necessary permission.
If a subscription is created with the direct_load option and an explicit user and password, the user ID and password are used once and not stored in rs_users. This user ID and password are used to log on to the primary Adaptive Server database (or Replication Agent) and the primary Replication Server, and should have the permissions described here.