Use the SAVE statement to save transaction statements to the transaction queue of the replica database ready for propagation to the master database.
The SAVE statement can be executed only in replica databases.
When the saved statements are executed in the master database, they must be executed by a user ID that has appropriate access rights and is defined in the master database. The saved statements are executed in the master database by using the access rights of the master user that was active in the replica database when the statement was saved. If a user in the replica database was mapped to a user in the master database, the SAVE statement uses the access rights of the user in the master database.
Parameters, clauses, keywords, and variables
▪ NO CHECK: Specifies that the statement is not prepared in the replica database. This option is useful if the statement would not make sense in the replica database. For example, if the SQL statement calls a stored procedure that exists in the master database but not in the replica database, then you do not want the replica database to try to prepare the statement. If you use this option, then the statement can not have parameter markers.
▪ error-handling-options: The default behavior for error handling with transaction propagation is that a failed transaction halts execution of the message; this aborts the currently-executing transaction and prevents execution of any subsequent transactions that are in that same message. However, you can choose a different error-handling behavior.
– IGNORE_ERRORS: Specifies that, if a statement fails while executing in the master database, then the failed statement is ignored and the transaction is aborted. However, only the transaction, not the entire message, is aborted. The master database continues executing the message, resuming with the first transaction after the failed one.
– LOG_ERRORS: Specifies that, if a statement fails while executing in the master database, then the failed statement is ignored and the current transaction is aborted. The failed transaction statements are saved in the SYS_SYNC_RECEIVED_STMTS system table for later execution or investigation, see SYS_SYNC_RECEIVED_STMTS. The failed transactions can be examined by using the SYNC_FAILED_MESSAGES system view (see SYNC_FAILED_MESSAGES) and re-executed from there by using the MESSAGE FROM REPLICA RESTART statement, see MESSAGE FROM REPLICA RESTART.
Note As with the IGNORE_ERROR option, aborting the transaction does not abort the entire message. The master database continues executing the message, resuming with the first transaction after the failed one.
– FAIL_ERRORS (default): Specifies that, if a statement fails, the master database stops executing the message.
▪ autosave-options: Auto save options can be used if the master database is also a replica database (for a different master database), and the statements must be propagated to the next tier.
– AUTOSAVE: Specifies that the statement is executed in the master database and automatically saved for further propagation.
– AUTOSAVEONLY: Specifies that the statement is NOT executed in the master database but instead is automatically saved for further propagation.
Return values
Error code
Description
25001
Internal error
Master database has exceeded the database size limit required to save the statement.
25003
Cannot save SAVE statements
25070
Statement can be saved only for one master in transaction.
Examples
SAVE INSERT INTO mytbl (col1, col2) VALUES ('calvin', 'hobbes')
SAVE CALL SP_UPDATE_MYTBL('calvin_1', 'hobbes')
SAVE CALL SP_DELETE_MYTBL('calvin')
SAVE NO CHECK IGNORE_ERRORS insert into mytab values(1,2)