Before Asking for Help…

I have a standard rule that I use before going and bugging a co-worker or posting via social media/message forum about a technical question I might have. I invoke this rule except in cases where there’s a production down or impaired situation and seconds count. Here’s the rule:

Before I go ask for help, I’m going to look for myself via the following methods:

  1. I will examine my previous notes, if I have dealt with this issue before.
  2. I will look at the documentation for the product (for SQL Server, this is Books Online).
  3. I’m going to make at least a few solid attempts via search engines to find a writeup matching my issue.

There’s a couple of reasons for this:

  1. When I proactively search in this way, I tend to retain the information better.
  2. I don’t waste the time of my co-workers or other community professionals.

I once had a co-worker who would ask anybody that came to him if they went down this type of checklist. If that person hadn’t, he would politely tell them to do so and if they still couldn’t find the answer, he’d be happy to help. It made the team around him better because he wasn’t the single cog of information. Others became more self-sufficient.

Specify the Parameter Names for Stored Procedures

I just ran across a case where a script was failing. Here’s the part that’s failing:

EXEC sp_addsrvrolemember 'MyDomain\MyGroup', 'SomeRole';
GO

Do you see the issue? If not, that’s understandable. Because this is correct:
EXEC sp_addsrvrolemember 'MyDomain\MyGroup', 'SomeRole';
GO

The problem with the first query is due to the default order of the parameters for the stored procedures. The one at the database level, sp_addrolemember, specifies the role first. The one at the server level, sp_addsrvrolemember, has the login name first. Unless you happen to know that little detail (either because you’ve been studying for a certification test or because you’ve been burned by this sort of thing before), you won’t catch the problem with the first query until it fails. There’s an easy way to handle this, and that’s just to specify the parameter names in your queries. If we do that with respect to the first case, we get:

EXEC sp_addrolemember @membername = 'MyDomain\MyGroup', @rolename = 'SomeRole';
GO

Not only does this avoid the type of syntax error produced by getting the order wrong, but it also makes the query very readable. I say the latter because if you’re dealing with SQL Server-based logins, sometimes it’s hard to tell what’s the user and what’s the role. By specifying the parameter, you know exactly which is which for that particular query. And while I’m using sp_addrolemember as an example here, it’s true of any execution of a stored procedure, especially ones that have a lot of parameters.

Boorish Behavior? No, Worse. Death Threats Against Developers/Designers.

I know DBAs and developers have a rocky relationship. However, I don’t believe we go as far as some of the fanatics in the gaming space. A friend of mine linked to this article:

BioWare writer quits after death threats to family

This isn’t the first occurrence, as the article reminds us of another incident just a month ago. Death threats? If this kind of stuff keeps up, we will see a mass exodus of top-notch developers and designers leave these communities. Building is cool, but not when you’ve got to put up with death threats.

And the thing that really caught my attention? This:

 “‘I was shown a sample of the forum posts by EA security,’ says Hepler ‘And it included graphic threats to kill my children on their way out of school to show them that they should have been aborted at birth rather than have to have me as a mother.’”

The fact that EA security is going through forums looking for this kind of thing says this isn’t a marginal occurrence or a trivial matter. If you game with folks who exhibit this kind of behavior, take a stand. This kind of stuff has got to stop.

Schneier’s Thoughts on the Future of IT Security and the Impact of the Internet on Power

If you’ve got an hour to spare, you might want to check out this presentation by Bruce Schneier where he gives his thoughts on the future of security (it’s evolving into a feudal model) and what the Internet means with respect to power. He talks a lot about privacy concerns, with some insightful thoughts about the how and why.

 

Bruce Schneier: Talks at Google

Windows Phone Security Advisory – Weakness in Security Protocol

If you’re using a Windows phone, versions 7.8 or 8, there is a new security advisory out with respect to weakness in one of the authentication protocols:

Microsoft Security Advisory (2876146) – Wireless PEAP-MS-CHAPv2 Authentication Could Allow Information Disclosure

There is a recommended security update – not in the form of a patch or download, but rather in a configuration change. Therefore, read through the Suggested Actions if the scenario applies to your or your environment. The suggested action requires the issuing of a certificate to the wireless access point (WAP) so that the phone can validate the WAP.

More on SQL Server Built-In Cryptography Options

I wrote a series of articles at MSSQLTips.com to cover the cryptographic algorithms that are available with Microsoft SQL Server. Basically, I distilled what the current view is on each algorithm and whether or not it’s okay to use. If you’re looking at securing data using the cryptography SQL Server provides, have a look:

This does cover through Microsoft SQL Server 2012, which adds SHA-2 to the hashing algorithms.