SQL Prompt is amazing and it’s my favorite tool. It’s actually what many people want first from Redgate because it makes coding much easier. One of the most used features is the reformat feature (CTRL+K,Y), since formatting really matters to developers.
One of the neat features of SQL Prompt is that you can format just a portionof your script. That means if you’re working on a large script and want to reformat just a part of it, you can.
Here’s how:
Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.
If you are wondering what permissions a role has, and don’t want to spend time searching and digging through Books Online, there are a few system procedures that can help. These will give you the permissions for a role, or all roles.
Let’s see how to use these.
Let’s say that you are wondering what a Processadmin can do. There is a procedure, sp_srvrrolepermission, that you can use to get the list of permissions. This can be run with no parameters, in which case you’ll get all roles and all permissions.
However, often you’ll want a more manageable set of data that a person can understand. Let’s see what processadmin can do.
Only two permissions here, so I can see that granting this isn’t going to affect security or databases.
The database has a related procedure, sp_dbfixedrolepermission, that looks for database roles. This can again be run without any parameters, as shown here.
If we include a role, we see just those permissions.
This is a short post, really about 5 minutes, based on my need to solve another issue. However, this is something a DBA should know, and it’s something I’ll likely use again.
The GDPR took effect in May of this year, at least with regards to enforcement. A few days after the May 25 date, a German court ruled against ICANN, the company that registers domain names on the Internet and manages the global WHOIS database. The case revolves around the information collected when you register a domain. ICANN wants multiple contacts, which they’ve required for decades. However, a company in Germany that is a partner, argued that the additional technical and administrative contacts were not required for fulfilling the business that both ICANN and EPAG (the German registrar) are engaged in. ICANN Is appealing the ruling, citing the need for clarification of what this means with regard to the law.
This is interesting to me, because a) it concerns data, and b) there is an interesting argument here to be made about what data is needed for a business purpose. I could see this being argued successfully either way, and not just in court. As a domain holder, does the registrar really need multiple different sets of personal information from me? Arguably, this is a convenience for them, one that is based on tradition. However, one could argue the other way.
It is a little scary that a court, with no expertise in some industry (Internet domain registration, in this case), will decide if there is an actual business need. After all, can a lawyer or judge really understand what data a business needs in their daily activities?
Maybe, maybe not, but I do think this forces businesses to actually stop and think about what data they collect, have a justification, and document that. That’s a good thing, because often I find business people just asking to collect data without any idea what they’ll do with the information. I also find technical people collecting data, not maliciously, but often to anticipate what might be asked of a system, or because they want to avoid rework and just decide to collect everything they can.
Data is precious, and while I don’t want to put many limits on what data businesses can collect, I also don’t want to them be able to collect anything, not disclose what they’ve collected, and not secure it properly. Having some limits, or at least forcing them to consider the risk of holding old, useless data, is likely a good thing for all of us.
Steve Jones
Listen to the MP3 Audio ( 3.7MB) podcast or subscribe to the feed at iTunes and Libsyn.
Many of us that are DBAs and/or sysadmins find ourselves with privileged access to many systems. We can often read the data that’s stored in these systems, whether that’s a relational database, a NoSQL store, or even a mail system. As a result, it is incumbent upon us to be trustworthy and maintain confidentiality with privileged information.
Overall I think most of us do this, but there are always some rogue administrators out there, some of which might take malicious actions. There have been a few people that were arrested or sued for hacking into systems, trashing backups, or causing other issues. Often those are emotional outbursts that disrupt operations, and many people are aware there is an issue. However, what if people weren’t aware they were being hacked in some way?
I ran across this story about some “admin” software being sold on a hacker forum site, which was marketed as sys admin software, but used to control other people’s computers without their knowledge. This is essentially a remote access trojan application that a developer sold to others who used it to steal data from their victims. The software developer was arrested and signed a plea agreement, knowing that it was used in a malicious manner.
For those of us that have privileged access, we might learn passwords of users as we watch them enter the value over and over. We certainly might work with their data to help them solve an issue or understand the manipulation taking place. We We may have auditing systems or logs that allow us to replay or examine the data values people have entered into applications. We do this with their permission and understanding, or at least someone’s permission. A user might not know we have substantial instrumentation, perhaps even the equivalent of a keystroke logger, but there will be some management that is aware of the existence of these tools.
While I’ve played a few pranks on people, moving keyboards or mice, I’ve always ensured they knew it was me in a short period of time. Using admin software to spy on others without their knowledge is a breach of trust and ethics, in my opinion. Even being asked to use this by management would be immoral for me.
Knowing this type of software exists, is important, and if you find it, I’d make sure you report it to management immediately, preferably to a few different people. If anyone is using tools to spy on users, they’re likely up to no good and I’d hope we would all attempt to put a stop to the practice.
Steve Jones
Listen to the MP3 Audio ( 4.6MB) podcast or subscribe to the feed at iTunes and Libsyn.
