win by decapitation…
So I’ve been working on a project to bring monitoring awesomeness to various SQL servers, without purchasing more RedGate SQL Monitor licenses and hopefully, without purchasing anything at all. Part of this project requires ODBC connections (at least it has in the testing so far), and during the testing I ran into a snag with the ODBC driver so I thought I would throw up a post in case anyone else runs into the same problem.
First, we do NOT use the standard SQL port. There is often debate about this in the community, but we believe that it stops many automated scanning attempts or scripts from running, which IMHO, makes it worth the extra work (which is a very small amount of extra work). If you use the standard 1433, then this won’t be a problem for you.
So I’m rolling along, as shown below, creating my ODBC connection…singing some ODB
So, like the chill DBA that I is, I swooped on over to my aliases and double checked them to make sure the fools weren’t trippin. Everything was looking a oh k. I wen’t through a battery of troubleshooting tests, netstat, wf.msc, stuff n other eliteness that you cannot even begin to comprehend…and everything was still looking a oh k. Double YOU tee EFF?
Well, the fix was quick and easy, once I started pushing buttons in a murderous fit of nerdrage. Seems like my own nubness with the ODBC connector is what cblocked me from getting connected. See, even though you have the aliases configured, ODBC doesn’t give a fuck. You have to configure it at the client level (it’s a driver, besbaleedat).
So there you go. Knowing that ODBC (and possibly other drivers) disregards your aliases might help you get connected quicker.
Cheers