• Permissions and Security in Dynamic Data Masking - Step 4 of the Stairway to Dynamic Data Masking
• Sharing SQL Prompt Code Snippets and Styles via the Redgate Platform
• Oracle optimizer removing or coalescing subqueries
• From the SQL Server Central Blogs - Logic Apps and Source Control (with PowerShell)
• From the SQL Server Central Blogs - Visualizing SQL

• Creating AAD Users in Azure SQL Database

Daily Coping Tip

Share photos of 3 things you find meaningful or memorable

I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate.

For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours.

It's Not Yours

This editorial was originally published on Jan 17, 2018. It is being re-published as Steve is at Technorama.

For most of my career, I've felt a tie to the systems I've managed or the code I've written. I've often said that a part of the code was mine, because it was something I'd written. Having some ownership of your work has often meant more pride in ensuring things are well implemented. The same thing goes for administering databases. When an employee feels personally responsible and accountable for  the database and its contents, usually they do a better job.

Most of us know that the systems we manage and the data they contain aren't really "ours", no matter how we might refer to them in conversation. We know that ultimately the data, applications, and hardware belong to our employers. Or, we should know that.

Apparently not everyone does. A contractor just pleaded guilty to stealing classified information from the US National Security Agency, about 50GB worth of data. This isn't a case of spying or malicious intent. Instead, the report is that the employee was a hoarder, just keeping copies of data for some unknown reason. Hopefully that's true.

Many of us will have copies of data that we use for different purposes. We might be building software, or testing queries, or some other task that requires data. We might want to conduct more in depth analysis in our spare time. Those are all positive goals, but none of them mean that we should have copies of data without authorization. We don't own the data, and we should always be sure if we are moving data to other systems, that those systems are secure and someone else has approved the action.

This becomes more important all the time. We have enough issues with data security and keeping our information away from hackers. We make plenty of mistakes with configuration in authorized development and test systems. There's no reason to add to the issues by treating data as our own personal asset, no matter how good your intentions.

Steve Jones - SSC Editor

Join the debate, and respond to today's editorial on the forums