When Vendor Tie-In Bites Back
Whilst by choice I spend a lot of my time working with open source and vendor-neutral technologies, I do have a lot of history with things like Microsoft ASP, and from time to time I find myself working on projects based on closed technologies. It is one of those projects that I’m working on this weekend. For their own reasons, the client needed this web app to be built using classic ASP and SQL Server 2000.
I probably ought to state now that I’m not sure if the problem I have here is one of vendor tie-in, or simply one of it-sucks-to-have-to-develop-with-SQL-Server, or if in fact both are the same thing. I should also point out that I’m not particularly trying to make a case for open source vs anything else, but am rather recounting my experience with that. But I digress. As I was going to be doing a lot of database work and therefore would need to use SQL Server’s Enterprise Manager and Query Analyser tools, I fired up my Windows XP box at the back of the desk (I had to dust it off) and worked from that. It seemed simplest, and would let the technology for the most part get out of the way.
Unknown Error
I’d been working away for a while before I’d realised I couldn’t query any of the tables in Enterprise Manager without an Unknown Error message coming back. Irritating to say the least, so I rebooted and tried again. Same story. I tried telling Enterprise Manager to forget all about the server it was connected to, then reconnected and tried again. Nothing. So I reinstalled all the SQL Server tools. Again, no joy. I became grumpy and went and made more coffee.
After a bit of googling, it became apparent that the fault could be fixed by upgrading MDAC to version 2.8. MDAC is basically just a bundle of database drivers, XML parsers and such. Silly old me only had version 2.7, so I downloaded the 2.8 installer, which promptly failed to install. Googling on that problem found a bunch of suggested solutions, none of which worked for me. Enterprise Manager is still broken.
Every Possible Chance
To be honest, I’m not surprised by the situation. The database toolset hasn’t really been updated in at least the six or so years that I’ve been using SQL Server. And the tools sucked back then too. The thing that really annoys me is that I’m running a XP workstation logged onto a Windows Active Directory domain, connecting to a Windows Server 2003 server running SQL Server 2000, and it doesn’t work. I can’t think what greater chance of success I could give it. On top of that, the killer is that there’s nothing I can do about it. I guess I could try reinstalling Windows XP on my workstation, but that holds no guarantees and would eat a considerable amount of my day.
Microsoft have a new version of SQL Server around the corner, which I was thrilled to hear came with a brand new toolset. Looks like even MS realised their tools were crap. However, on digging deeper (and I hope someone can tell me I’m wrong) it appears that these tools are not stand-alone as present, but are integrated into Visual Studio.NET. I can imagine the meeting that made that decision.
Comparing SQL Server with MySQL
The database server I work with most of the time is MySQL. The only real justification that can be brought for comparing the likes of SQL Server and MySQL is that they are both common choices for web applications. If you’re developing your web app on a Microsoft platform, SQL Server is really the only choice unless your app is hefty enough to require an Oracle solution. SQL Server is actually a really good product (its tools aside). It’s a robust, scaleable, transactional beast of a server that you can hang some pretty serious enterprise-level applications off. It doesn’t compete with Oracle when you’ve got serious numbers of users, but for the SME it’s perfect.
MySQL on the other hand only has a fraction of the features available in SQL Server. Although there’s some good stuff coming, the current stable release doesn’t have views, stored procedures, or even subqueries. But, it’s fast, light, and perfect for web applications. Once stored procs and subqueries make it into the stable release, there’s no holding it back. Most importantly, however, there’s no vendor tie-in. MySQL is open source – the result of which is that anyone can come along and write a fully featured set of development tools for it. Even on OS X, which is a fairly obscure platform in the scheme of things, I can find several robust MySQL admin tools to work with. If I come across a bug in one, I can switch to another.
Tie-in
It’s the simple fact that vendor tie-in reduces the number of options when things go wrong that makes it a very hard business decision to take. Choose product A and be reliant on Company A when things go wrong. Choose product B and have the choice of going to Company B, X, Y or Z, or hiring a developer to fix it for you, or trying out a new release or … the number of options are large. Throw into the mix that product A costs thousands, and product B is free, and it becomes a no-brainer.