T-SQL Tuesday #98: Technical Challenges

Dave Mason T-SQL Tuesday

For T-SQL Tuesday #98, Arun Sirpal (b|t) asks us to write about a time when we faced a technical challenge that we overcame. Thanks for asking, Arun!

Since I blogged about passwords recently, let's continue with that topic. My technical challenge was installing a third party vendor's software (it uses SQL Server). It kept failing with a misleading error message from the installation package. Gasp! "An error with a third party application?" "A disingenuous error message?" Surely you can't be serious!

I'm sure most of you have encountered a less than helpful error message similar to this:

Dave Mason T-SQL Tuesday - Error Message

To be fair, my error message did mention something about "ODBC". I spent a fair amount of time with the vendor's tech support. All of them assumed there was an authentication error on my part. But I easily demonstrated in both SSMS and a Data Link File that this wasn't the case. Eventually, I tracked the problem down to the password. It had many special characters in it, and IIRC, it was a semi-colon that was the culprit. Oversights happen sometimes. We all understand that. A more helpful error message would have saved the day, though. Something like this doesn't seem that hard:

Dave Mason T-SQL Tuesday - Microsoft Data Link Error

So what's my solution? I don't know. I lost my hair and now I've got this comb of experience. Instead of calling it a "solution", let's go with "advice": use alpha-numeric passwords initially when you are installing software. Heck, you might even want to do this when you're creating a new account online. If that's not good enough to meet the password requirements, use the least complex password that works. After the software is installed (the account is created, or whatever), go back and change the password to something longer and more complex. At least then you'll take the vendor's password handling ability (or lack thereof) out of the equation.