Advanced Replication Guide : Bulletin board parameters : Parameters on master
  
Parameters on master
The Duration column indicates whether the parameter value lasts for only the current transaction (T) or whether it lasts until changed (C).
The R/W column indicates whether the value can be only be read (R/O) or can be read and written/updated (R/W).
SYNC_DEFAULT_PROPAGATE_ERRORMODE
This parameter controls what the server does when an error occurs while propagating a message. The possible values are IGNORE_ERRORS, LOG_ERRORS, or FAIL_ERRORS. The meanings of these values are the same as for the SAVE command. See the description of the SQL command SAVE in solidDB® SQL Guide.
Note that the error-handling mode may be set in three different ways (by setting a bulletin board parameter, by specifying an optional keyword with the SAVE command, or by using the MESSAGE APPEND PROPAGATE TRANSACTIONS statement). See Specifying recovery from fatal errors for more details.
Factory Value: By default, the system behaves as though the error mode is FAIL_ERRORS.
Duration: C
R/W: R/W
SYNC_DEFAULT_PROPAGATE_SAVEMODE
The possible values are AUTOSAVE, AUTOSAVEONLY, and NULL. Null means that the propagated transaction is not automatically saved. See Specifying recovery from fatal errors for more details.
Factory Value: NULL
Duration: C
R/W: R/W
SYS_ERROR_CODE
This parameter can be used together with the SYS_ROLLBACK parameter. Users can set their own error code in this parameter to indicate the reason why the transaction was rolled back. This error code is returned after roll back.
The error code specified using this parameter is also returned to the replica database as part of the MESSAGE FORWARD or MESSAGE GET REPLY command.
Example:
PUT_PARAM(
  ’SYS_ERROR_CODE’,’99000’
);
Factory Value: None
Duration: T
R/W: R/W
SYS_ERROR_TEXT
This parameter can be used together with SYS_ROLLBACK parameter. Users can put their own error text in this parameter to indicate the reason why the transaction was rolled back. This error text is returned after roll back.
Example:
PUT_PARAM(
  ’SYS_ERROR_TEXT’,
  ’User defined error text’
);
Factory Value: None
Duration: T
R/W: R/W
SYS_IS_PROPAGATE
This parameter value is YES if the transaction is a propagated transaction that is being executed in the master. For non-advanced replication transactions, the value of this parameter is NULL.
Factory Value: None
Duration: T
R/W: R/O
SYS_NOSYNCESTIMATE
In many cases, either an incremental refresh or a full refresh would synchronize the replica. An incremental refresh is usually the most efficient choice. However, there are cases where a full refresh is more efficient. As an extreme example, if 99% of the rows in a table have been deleted, then it is more efficient to send a full refresh (1% of the rows) than to send each individual row that was deleted (99% of the rows).
By default (SYS_NOSYNCESTIMATE=None), the server calculates whether an incremental refresh is more efficient than a full refresh and then chooses the one that it thinks is more efficient.
You can turn off the calculation and thus force the server to use an incremental refresh by setting SYS_NOSYNCESTIMATE to Yes.
This parameter is used only rarely.
To disable the estimator, execute on master:
SET SYNC PARAMETER SYS_NOSYNCESTIMATE ’YES’; COMMIT WORK;
To enable the estimator (=default), execute on master:
SET SYNC PARAMETER SYS_NOSYNCESTIMATE NONE; COMMIT WORK;
Factory Value: "None". This means that the estimator is not disabled. This does not mean that there is no factory value.
R/W: R/W
SYS_ROLLBACK
This parameter is used inside a transaction when the execution of the transaction should be rolled back. If the value of this parameter is set to YES, then using the PUT_PARAM function causes solidDB® to stop execution of the transaction and roll back all statements executed already. Rollback of the transaction will cause the execution of the synchronization message to halt. Note that COMMIT WORK and ROLLBACK WORK commands are not allowed in propagated transactions.
SYS_ROLLBACK can be used, for instance, if a transaction detects a fatal error such as a referential integrity error in the database.
Example: PUT_PARAM(’SYS_ROLLBACK’,’YES’);
Factory Value: The factory value is "No".
Duration: T
R/W: R/W
SYS_TRAN_ID
This parameter is valid only for propagated transactions, that is, when a propagated transaction is executed in the master database SYS_TRAN_ID will contain the original transaction's id from replica database. For non-advanced replication transactions, the value of this parameter is NULL.
Factory Value: None
Duration: T
R/W: R/O
SYS_TRAN_USERID
This parameter is valid only for propagated transactions, that is, when the propagated transaction is executed in the master database SYS_TRAN_USERID will contain the original user id used when the transaction was executed in the replica database. The transaction is executed in the master database using the access rights defined to this user id. If the user id was mapped from the replica to a master user id, the access rights used during execution in the master database are the access rights of the master user id (not the original replica user id).
For non-advanced replication transactions, the value of this parameter is NULL.
Factory Value: None
Duration: T
R/W: R/O
See also
Bulletin board parameters