SQL Server Apply Parameters
The following parameters are valid for the SQL Server Apply Process:
Process Parameters
- process – The only possible value is apply
- id – The Apply Process id
- dbtype – Type of RDBMS, the only possible value is mssql
- capturename – The name of the Capture Process which is providing the data to be used
Database Connectivity
- server – Host name or IP address of the database server
- port – Database port
- dbname – Database name
- user – Database User name
- password – Database User password
Transaction Processing Parameters
- ddlcreate – Used to define the Apply Process behaviour when creating a table, if a table with the same name is found. The table is specified in schema _name.table_name format. In order to specify the list of the tables, each table must be separated by comma. The % symbol may be used in order to match any number of characters. It has the following options:
- skip– do not run DDL create command if the table already exists
- recreate – to drop the existing table and recreate it
- ddldrop – Used to define the Apply Process behaviour when dropping a table, if a table with the same name is not found. The table is specified in schema _name.table_name format. In order to specify the list of the tables, each table must be separated by comma. The % symbol may be used in order to match any number of characters. It has the following option:
- skip – do not run DDL drop command if the table doesn’t exist
- ddlprocessing – Determines if DDL must be processed based on the user statement or generated based on the dictionary changes. The possible values are:
- native – to process DDL based on the user statement (default value)
- dictionary – to generate DDL based on the dictionary changes
- map – to generate DDL based on the dictionary and the objects’ transformation rules
Note – For Homogeneous type of replication it is recommended to use "native" method of DDL processing. The "dictionary" value is commonly used in the case of Heterogeneous replication. “map” is used when the DDL statement must be reformatted following objects' transformation rules
- ldtxsize – Determines the number of records to be inserted in one transaction at the Initial Load stage. If the value is 0 the table is loaded in a single transaction. The default value is 500000
- batchmode – This parameter is to specify transaction processing method. The possible values are:
- 0 – apply all the data changes within transactions as they were occurred in Source (default value)
- 1 – combine and processes set of transactions in a single transaction
- 2 – combine set of the transactions into a single transaction and analyse data within it to produce the only one net change for each row that has been changed
Note – setting “batchmode” parameter to “2” requires all the foreign keys to be disabled, otherwise the Apply Process may failed with the “foreign key violation” error
- skipapply – Used to define the behaviour of the Apply Process when inserting data, which was originally produced by Apply Processes in the Source Database as part of the “loop-back” control function, in that, this Apply Process will insert, or ignore the data. The Apply Processes to be skipped are specified by ids separated by comma. In order to specify all Processes the “all” value to be used. In order to avoid skipping any Apply Processes the “none” value to be used. The default value is “none”.
Filters and Local Transformations
Other Parameters
- autostart – Determines if the Apply Process must be run automatically. Possible values are:
- 0 – do not run the Apply Process automatically (default value)
- 1 – to run the Apply Process automatically
- debuglevel – The level of debugging. Possible values are 0-15
- repuser – Determines if the Apply Process must represent itself as SQL Server replication process. The possible values are:
- 0 – do not represent itself as SQL Server replication process (default value)
- 1 – to represent itself as SQL Server replication process
Note – You should be aware that if the repuser parameter is set to “1” and is invoked, then when delivering data to a SQL Server Target Database, any changes of objects marked as ‘Not for Replication’ (Identity columns, table triggers, foreign keys and check constraints) will be handled in exactly the same way, as they would be produced by an SQL Server replication agent. As an example, any triggers which are created with the “Not for Replication” option will never be fired.
------ >>> TBR
REST API:
- Endpoint: https://repstance_url/configure/process
- Method: POST
- Header:
- Content-Type: application/json
- X-Token: token
- Body:
{
"command": "prepare",
"parameters": [
["process","apply"],
["id","applyID"],
["dbtype","mssql"],
["capturename","captureName"],
["server","databaseHost"],
["port","databasePort"],
["user","username"],
["password","password"],
["dbname","databaseName"],
["autostart","{0|1}"],
["debuglevel","{0-15}"],
["repuser","0|1"],
["ddlcreate","objectMask:options"],
["ddldrop","objectMask:options"],
["ddlprocessing","native|dictionary"],
["skipapply","skipapplyMask"]
]
}
Server response:
- HTTP Status – status of the command, possible codes are:
- 200 – if no error occurs
- 422 – if error occurs
- Body:
{
"Status":"{Failed|Completed}",
"Message":"The command execution details"
}
CLI Syntax:
repcli prepare process=apply id=applyIDdbtype=mssql\
capturename=captureName \
server=databaseHostport=databasePort\
user=username password=password \
dbname=databaseNameautostart={0|1} \
debuglevel={0-15}repuser={0|1} \
ddlcreate=objectMask:options \
ddldrop=objectMask:options \
ddlprocessing=native|dictionary \
skipapply=skipapplyMask