Many Data Masker rules require that the table you want to mask must have a primary key/unique constraint.  

If you add a Primary Key to the table, refresh the table in Data Masker to resolve a missing primary key warning. 

Alternatively, you can use Data Masker to resolve missing primary key issues either by:  

• Converting the rule to a Sync Manager (Recommended)
• Using command rules to generate a temporary Primary Key 

Converting the rule to a Sync Manager (Recommended)

If you receive a warning about missing primary keys, Data Masker may offer you the option to convert the rule to a sync manager.

A Sync Manager Rule does not rely on user-provided primary keys. It treats the unique combination of columns being masked as the keys to update the rows. 

It has the added advantage that it can mask multiple rows with the same data consistently.

Convert to a sync manager rule by selecting "Convert to sync manager" when validation appears:

Using command rules to generate a temporary Primary Key 

If you do not want to change the source data schema, you could use Command Rules to add a temporary Primary Key during masking set runs. Use the following steps:

Step 1: Configure a command rule to execute a statement that adds a column as the Primary Key, sets the constraint name, and populates it with incrementing integers. This is an example:

ALTER TABLE [<YourDatabase>].[<YourSchema>].[<YourTable>] ADD [DMSIdentityCol] INT IDENTITY(1, 1) CONSTRAINT DMS_<YourTable>_PK PRIMARY KEY; 

Step 2: To ensure the new PK constraint is visible for the next stage of your masking set, add an Index Refresh rule. 

Step 3: Use rule blocks to ensure the Command Rule and Index Refresh Rule run before any rules that rely on a Primary Key. 

Step 4: Configure a Command Rule to drop the Primary Key constraint after the masking rule. This is an example:

ALTER TABLE [<YourDatabase>].[<YourSchema>].[<YourTable>] DROP CONSTRAINT DMS_ <YourTable> _PK, COLUMN [DMSIdentityCol]; 

Example: