Data Masker for SQL Server is a great tool ensuring the data you use in non-production environments is compliant with any regulations by obfuscating and changing sensitive data. This is part of a series of posts on Data Masker from Redgate Software.
I needed to check something for a customer recently in Data Masker. However, I didn’t want to mask my existing database. Instead, I wanted to make a copy of the db and then use my masking set. However, the existing masking set includes a setting for the connection string.
When I first started using Data Masker, this was something I hadn’t thought about. The new masking set dialog asks for an instance/database name, and then this gets hidden. The first time I needed to change the connection, I hunted through all the menus, looking for a project option.
The Controller
I was lucky enough to work with the developer of the Data Masker product, who contracted with Redgate for a bit after the acquisition. I emailed him in frustration and he spent a little time explaining the architecture decision. Since Data Masker can connect to multiple databases for different situations, the connection is actually in the controller. This allows one masking set to handle multiple databases.
As you can see below, all of my rules are indented below the controller. This means they all use the connection setting in the controller.
To change to connection string, I click “Edit Rule” with the controller highlighted. This lets me see all the settings right away.
I can change the database name (or other settings) and then I always click “Test Connection” as I have been known to mis-type things, and this isn’t a drop down.
Don’t forget to click “Update Rule Controller”. There is no save here. That’s what does it.
Data Masker is an incredibly powerful tool for protecting sensitive data. I see more and more customers using it all the time to comply with GDPR and other government regulations. If you’ve never tried it, download an eval today and check out our library of articles.