Data Masker

Table Mover Rules

Copy rows from a table in a Rule Controller to a different target SQL Server or Oracle database (see Cross Database Login Panel). The target server needn't be included in any rule controller of the masking set.

Conceptually, a table mover is like running an INSERT statement against the target database for each row of the source table.

Core concepts

The Target Database

The target database does not have to be located on the same server as the source database and can be of a different type than the source database. Both SQL Server and Oracle target databases are supported.

The Target Table

The target table can be any table which can be inserted into by the login information specified in the Cross Database Login Panel. The target table does not have to have the same name or structure as the source table.

The Target Table Columns

The columns in the target table can have different names than those of the source table and, if of a different datatype, should be of a datatype suitable for automatic conversion by the target database upon insertion.

Target Table Suitability

If the target table has more columns than those specified, those columns must either support NULL, or have default values. There is no way to specify default values for columns not included.

Table Movers Append to the Target Table

Table movers always append to the target table. If you want to insert into a clean table, consider deleting or truncating the target table in a command rule, or cross database command rule.

Advanced concepts

Moving a Subset of the Source Table

It is possible, using the Where Clause feature, of the Table Mover rule to configure the rule to move only a subset of the rows in the source table to the remote table.

Error Management and Handling

An error inserting the data into the remote table will normally stop execution of the masking set and all further rules. If required, the error can be trapped and the execution of subsequent rules will be possible.

Important Note: The error manager does not trap errors on a row-by-row basis. In other words if it is not possible to insert a row (perhaps due to a primary or foreign key violation) the rule will error. If that error is trapped, then the rule will just stop and no further rows will be moved. It will not attempt to move further rows to the remote table. In such a case, the remote table will be in an indeterminate state.


Didn't find what you were looking for?