solidDB Help : solidDB reference : SQL: Statements : MESSAGE : MESSAGE APPEND
  
MESSAGE APPEND
Note Applies to only solidDB Advanced Replication configurations.
MESSAGE unique‑message‑name APPEND
   [PROPAGATE TRANSACTIONS [{IGNORE_ERRORS | LOG_ERRORS | FAIL_ERRORS}]
   [WHERE {property‑name {=|<|<=|>|>=|<>} 'value‑string' | ALL}]]
   task-list
where:
task-list::=
   [{REFRESH | SUBSCRIBE} publication‑name[(publication‑parameters)] timeout[(seconds)] [FULL]]
   [REGISTER PUBLICATION publication‑name]
   [UNREGISTER PUBLICATION publication‑name]
   [REGISTER REPLICA]
   [UNREGISTER REPLICA]
   [SYNC_CONFIG ('sync‑config‑arg')]
Access requirements
▪ MESSAGE APPEND PROPAGATE TRANSACTIONS: Requires a valid master user
▪ MESSAGE APPEND REFRESH: Requires a valid master user
▪ MESSAGE APPEND {REGISTER PUBLICATION|UNREGISTER PUBLICATION}: Requires refresh access to the publication
▪ MESSAGE APPEND {REGISTER|UNREGISTER} REPLICA: Requires SYS_SYNC_ADMIN_ROLE or SYS_SYNC_REGISTER_ROLE
▪ MESSAGE APPEND SYNC_CONFIG: Requires SYS_SYNC_ADMIN_ROLE or SYS_SYNC_REGISTER_ROLE
Usage
Use the MESSAGE APPEND statement to append any of the following tasks to a message that has been created in the replica database by using the MESSAGE BEGIN statement:
▪ 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 can be executed only in replica databases.
Parameters, clauses, keywords, and variables
▪ WHERE: Propagates only those transactions where a transaction property that is defined with the SAVE PROPERTY statement meets specific criteria.
▪ 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.
▪ task-list:
– REFRESH [FULL]: Refreshes the replica database from the master database. Include arguments to the publication (if they are used in the publication). The parameters must be literals; you cannot use stored procedure variables, for example. Using the keyword FULL does a full refresh of the specified publication instead of an incremental refresh. The specified publication must be registered.
Note The keywords REFRESH and SUBSCRIBE are synonymous but SUBSCRIBE is deprecated in the MESSAGE APPEND statement.
– REGISTER PUBLICATION: 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.
– UNREGISTER PUBLICATION: Removes an existing registered publication from the list of registered publications in the master database.
– REGISTER REPLICA: 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 multi-master 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 after catalogs are created in a synchronization environment. For synchronization to the replica, a new catalog for each master database is required.
Notes
▪ 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 can have multiple masters, but only if the node has a separate replica catalog for each master catalog.
▪ A single replica catalog cannot have multiple masters.
– UNREGISTER REPLICA: Removes an existing replica database from the list of replicas in the master database.
– SYNC_CONFIG: Downloads master users from the master database to the replica database, see Downloading master users to a replica database. The input argument of the SYNC_CONFIG task defines the search pattern of the user names that should be downloaded. SQL wildcards (such as the symbol %) that follow the conventions of the LIKE keyword are used in this argument. For more information, 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;
Go up to
MESSAGE