Tim Ford recently shared his frustrations with vendor applications and support and then tagged me for a response. I have been tagged so many times in the past week I am starting to feel like Tara Reid on Spring Break.
I have had so many frustrations with vendor products that I gave up trying to keep track of them years ago. Just the other day I had a vendor product essentially give my server amnesia. The workaround? We split the databases out to a different server so the creation of the linked server would not overwrite the internal sysservers entry. Nice, huh? Never use one piece of hardware when you can use two at double the price! Must be a government project.
Anyway, back to the post. We never touch a vendor application. Ever. Well, I don’t at least. I am sure others don’t think twice about adding some custom code to a vendor application, say if you want to run a report and decide to put your own stored procedure inside the database. But they should otherwise then run the risk of either losing support or being forced to pay higher support costs as a result of their desire to put one tiny little stored procedure into that vendor database.
So, if the vendor happens to find those custom objects you would get charged out the bajoobas, and no one ever thinks twice to ask “hey…is it okay for me to be mucking around like this?” or “What the hell are bajoobas?”
I could go on, but why bother. The bottom line is we do not touch vendor code, we request the vendor to make the changes. Sometimes they do, sometimes they don’t. Sometimes the vendor application is fairly benign, other times they are quite intrusive but in either case we have to keep the instance up and running. If problems are identified as being vendor related we keep our hands off.
