Amnesia Again, I Think, but I Don't Remember, Really

I recently had (yet another) vendor product give my server amnesia. Yessir, just like before, a simple SELECT @@SERVERNAME was returning a NULL value. The net result of this is that anything written that depends upon @@SERVERNAME to return an actual value will not work.

Now, last time this happened, I made a casual reference to the name of the vendor. This vendor has been more than fair to me in our past engagements. They provide me with great support, they give me a voice into the direction of their products, and they also give me speaking and writing opportunities. And I returned their kindness by airing their dirty laundry for all twelve of my readers to see.

I was quite fortunate that after pouring gasoline on the bridge and lighting the match that this same vendor simply walked over, put out the match, and told me that “you know, you have a spot on your shirt.” I was gnawing on the hand that feeds me and was given a gentle reminder of that fact.

I shall not press my luck again this time. The vendor shall remain nameless. Their lousy code, and lack of support, will still be noted.

When we contacted support and notified them regarding the matter we were told that instead of using @@SERVERNAME, we should just “switch” to using the following:

SELECT SERVERPROPERTY(‘servername’)

Now, two things struck as wrong here. First was their suggestion that I go about making changes to my environment in order to give the appearance as if their product is working swimmingly. It reminds me of the old joke where a man visits a doctor:

Man: “Doctor, it hurts when I do this (moves arm).”

Doctor: “Then don’t do that.”

Sorry, but that left me feeling less than warm. I tried to offer the standard workaround which was to create a DNS alias and have the product use the alias as the servername when the linked server gets created. I was essentially told that the product won’t work unless we let it do everything it needs to do. (By the way, this would include NOT naming anything in our environment with the same name as the product, which I found a very odd requirement).

The second thing that struck me was “The Hell? They are making changes to the internal system tables, and then telling me to look the other way?” Microsoft discourages making ad-hoc changes to system tables, so how is it that this vendor felt that what they are doing was OK? If you see my earlier post you will understand that the actions they took cannot be done using the GUI, and must be done behind the curtain. And now I am left wondering what other changes they have made that I am supposed to just ignore, right?

To the best of my knowledge, changes to system tables are not a supported action by Microsoft. I am not certain if any lines are crossed with this particular issue, but I would prefer if vendor installs did not violate my system tables. Is it too much to ask for vendors to leave my instance in the same working state as when they found it?

A while back I had toyed with the idea of creating a wiki entry that would list out vendors, products, and known installation issues. And I would love to do exactly that, except I do not want to seem…well…as being “difficult” for vendors to work with. In fact, the opposite is true. I want to help people to know the possible issues they need to be aware of so that when using the products they are not surprised to find out a month later that their backups have been failing. And if this prompts the vendors to produce less crappy code than before, well isn’t that a good thing?

So, what I have decided to do instead is to create a wiki entry that simply gives you a script to run before and after a vendor install. My hope is that the community will add to the wiki entry and script over time, but I wanted to help get the ball rolling.