SQL Guide : solidDB® SQL statements : MESSAGE : MESSAGE APPEND
  
MESSAGE APPEND
MESSAGE unique_message_name APPEND
 [
 PROPAGATE TRANSACTIONS
 [ { IGNORE_ERRORS | LOG_ERRORS | FAIL_ERRORS } ]
 [WHERE { property_name {=|<|<=|>|>=|<>} ’value_string’ | ALL } ]
 ]
[ { REFRESH | SUBSCRIBE }
publication_name[(publication_parameters)]
timeout[(timeout_in_seconds)]
[FULL]
]
[REGISTER PUBLICATION publication_name]
[UNREGISTER PUBLICATION publication_name]
[REGISTER REPLICA]
[UNREGISTER REPLICA]
[SYNC_CONFIG (’sync_config_arg’)]
Usage
The MESSAGE APPEND statement append tasks to a message that has been created in the replica database with the MESSAGE BEGIN statement. The tasks include the following:
▪Propagate transactions to the master database
▪Refresh a publication from the master database
▪Register or unregister a publication for replica subscription
▪Register or unregister a replica database to the master
▪Download master user information (list of user names and passwords) from the master database
The MESSAGE APPEND statement applies only to advanced replication configurations and it can only be issued on the replica databases.
The PROPAGATE TRANSACTIONS task may contain a WHERE clause that is used to propagate only those transactions where a transaction property defined with the SAVE PROPERTY statement meets specific criteria.
Using the keyword ALL overrides any default propagation condition set earlier with the following statement:
SAVE DEFAULT PROPAGATE PROPERTY WHERE property_name {=|<|<=|>|>=|<>} ’value’
This enables you to propagate transactions that do not contain any properties.
The REGISTER REPLICA task adds a new replica database to the list of replicas in the master database. Replicas must be registered with the master database before any other synchronization functions can be performed in the replica database.
Synchronizing each master database to the replica in a multimaster environment requires registration of a replica to each master database by setting up catalogs. One replica catalog can register only to one master catalog. This statement performs the actual registration once catalogs are created in a synchronization environment. For synchronization to the replica, a new catalog for each master database is required.
Note  
▪A single-master environment does not require the use of catalogs. By default, when catalogs are not used, registration of the replica occurs automatically with a base catalog that maps to a master base catalog, whose name is given when the database is created.
▪A single replica node may have multiple masters, but only if the node has a separate replica catalog for each master catalog.
▪A single replica catalog may not have multiple masters.
The UNREGISTER REPLICA option removes an existing replica database from the list of replicas in the master database.
The REFRESH task may contain arguments to the publication (if used in the publication). The parameters must be literals; you cannot use stored procedure variables, for example. Using keyword FULL with REFRESH forces fetching full data to the replica. The publication requested must be registered. The keywords REFRESH and SUBSCRIBE are synonymous; however, SUBSCRIBE is deprecated in the MESSAGE APPEND statement.
The REGISTER PUBLICATION task registers a publication in the replica so that it can be refreshed from. Users can only refresh from publications that are registered. In this way, publication parameters are validated, preventing users from accidentally subscribing to unwanted subscriptions or requesting ad hoc subscriptions. All tables that the registered publication refers to must exist in the replica.
The UNREGISTER PUBLICATION option removes an existing registered publication from the list of registered publications in the master database.
The input argument of the SYNC_CONFIG task defines the search pattern of the user names that are returned from the master database to the replica. SQL wildcards (such as the symbol %) that follow the conventions of the LIKE keyword are used in this argument with a match_string, which is a character string. For details on using the LIKE keyword, see Wildcard characters.
Return values
Error Code
Description
13133
Not a valid license for this product
25004
Dynamic parameters are not supported
25005
Message message_name is already active.
25006
Message message_name not active
25015
Syntax error: error_message, line line_number
25018
Illegal message state.
An appending message in the replica must be placed between the MESSAGE BEGIN and MESSAGE END statements.
25024
Master not defined
25025
Node name not defined
25026
Not a valid master user
25028
Message message_name can include only one system subscription
25035
Message message_name is in use.
A user is currently creating or forwarding this message.
25044
SYNC_CONFIG system publication takes only character arguments
25056
Autocommit not allowed
25071
Not registered to publication publication_name
25072
Already registered to publication publication_name
Examples
MESSAGE MyMsg0001 APPEND PROPAGATE TRANSACTIONS;
MESSAGE MyMsg0001 APPEND REFRESH PUB_CUSTOMERS_BY_AREA(’SOUTH’);
MESSAGE MyMsg0001 APPEND REGISTER REPLICA;
MESSAGE MyMsg0001 APPEND SYNC_CONFIG (’S%’);
MESSAGE MyMsg0001 APPEND REGISTER PUBLICATION publ_customer;
See also
MESSAGE