Pr3++yG33kyTh1ng

There is a lot of stuff I just don't want to know, you know?
I'd hate to know (for instance) what the guy in the cubicle next to mine makes. Having full administrative rights over the Active Directory domain and all its data makes finding that kind of stuff out pretty simple, but it isn't anything I should know.
My company houses all this information in a database which uses SAP as a front-end. I'm responsible for ensuring that the data is available to the people in Human Resources and to no one else, but to do this I regularly need to test connectivity from the SAP front-end to the database.
I could pull up my own information, but even that is ethically questionable as I don't know what reports are being filed and secret assessments created.
The solution we employ is to use a series of specialized files in place of the standard SAPLogon.ini files. These files contain the list of databases available to the user through the interface. By creating the proper environment at the time of log on, we can restrict the access.
For testing purposes, my SAPLogon.ini file directs my SAP account to a dummy database for HR data. Not only does it not contain valid user information, it isn't even in a currently used language as far as I can tell.
As long as the database matches the permissions and is on the same SQL server as the real database, my test is about as valid as it can get without viewing sensitive information.
As I.T. people we need to remember that just because we have the access is no indication that we should use the access.