|
|
|
babysitting Microsoft
Saturday, January 9 2010
The coldsnap continued, with temperatures ranging from the single-digits to the low 20s. Nevertheless Gretchen managed to get a final harvest out of our garden. Yes, you read that right. I wrote garden, not greenhouse. There were still some collard greens on a stalk that had been in a state of suspended-animation since November. The leaves had frozen solid and turned a rich green, but Gretchen found that they were perfectly delicious once cooked.
I spent much of the day suffering at the hands of software. I don't mean just any software, mind you. I'm specifically referring to Microsoft's implementation of the SQL database language (and all the related habitat necessary to maintain a database that can be queried in the SQL language). While I normally consider myself a mild-to-moderate anti-Microsoft partisan, I routinely use their desktop software, since it best matches my mixture of needs and preferences. I also have a long history with their SQL software (called Transact SQL or TSQL). It was the platform on which I first learned to program databases roughly eleven years ago. Since then, I've moved on to mostly using MySQL, the open source SQL. At first MySQL had seemed like a cut-rate interloper, what with its lack of stored procedures and the hippie laxness of its data integrity enforcement. But over the years I've come to find that it just works and that hippie laxness is more of a feature than a bug. For example, it's good to be able to simply edit the value of an autoincrementing field that needs changing without having to go through a huge hassle.
Today, though, I was using Microsoft's TSQL again for the first time since that brief Toyota gig in May of 2006. I was trying to simply migrate a large TSQL database from one hosting environment to another. Such things need to be done on occasion. I'd gotten used to the world of MySQL, where you just "script out" the database into a mess of MySQL statements. It all ends up in one file: the table definitions, the constraints, the keys, and all the data. You run the script on your new host and your entire database is recreated as it was on the other host. The details of how this happens are unimportant; all that matters is that the database gets copied from one place to another. There's no babysitting (well, usually there's none) and there's no wondering if everything was transferred. It just works.
In the world of Microsoft's TSQL there's a functionality that is similar to this, though the interim file is not a human-readable text file full of SQL statements. It's something called a .BAK file and it has a typically-messy proprietary Microsoft format full of strange non-ASCII characters. On your source SQL Server host, you backup to create a .BAK file, then you FTP into the SQL Server source host, download the file, upload it to the SQL Server destination host, and restore it to make the new copy. It's a clumsy process because it cannot be done from a web page that, say, produces a download to your client computer. And it requires FTP access to the SQL Server host, which is not actually very common. So you end up producing a .BAK file and then creating a trouble ticket so some schmoe in Bangalore can email it to you.
But then it turned out that the destination SQL Server host, which in this case was a cut-rate plan from Godaddy.com, does not permit restoring from a .BAK file that hadn't been created on that host. In other words, .BAK had been eliminated as a possible medium for replicate a TSQL database. Godaddy's reasoning for this was that .BAK files from other sources expose their servers to exploits, and Microsoft's best practices specifically state "hosting providers should not enable users to restore .bak files from sources outside the hosting provider." That left only one other option: creating the empty tables and stored procedures from scripts and then populating them individually through CSV (comma separated values) files. Forcing users to rely on such an awkward and error-prone technique gets to the heart of what is fundamentally wrong with Microsoft as an ongoing software concern: they don't seem to understand what computers are for and what they are good at. Computers are good at automating complex, repetitive tasks such as the copying of a database and its data from one host to another. People, on the other hand, are good at judging the quality of a painting, negotiating a contract, or entertaining a roomful of technophobes. That Microsoft would propose a database copying procedure that required me to manually export and import CSV files for each table in a database isn't just ludicrous, it's Kafkaesque.
In the shipping industry, the invention of the shipping container allowed ports to run much more smoothly and with much less manpower than they had in the past, since the new containers were large units that could be kept intact all the way from the manufacturer to the distributor. If Microsoft had come up with one of their "solutions" for international shipping, it would involve opening up and emptying shipping containers at every port, only to pack the contents back up again to have them continue on.
At some point I discovered that someone had actually developed a mechanism to completely script-out a Microsoft database, but it hadn't been introduced until 2005. Still, even this mechanism was essentially useless to me, because there was no way to automatically read this script other than to copy and paste it into a form. But the database in question was over 300 megabytes in size, far too big to be handled that way.
In the end I decided to try a system called SQL Server Import and Export Wizard (part of SQL Server 2008 Express) that could supposedly automate the copying of all the records in all the tables of one database to another. (It still leaves the task of copying over the stored procedures and indices to someone/something else, thereby ensuring all sorts of delicious points of failure.)
But the SQL Server Import and Export Wizard turned out to be an unhelpful piece of junk. I started the "wizard" running and it seemed to be going nicely. An hour passed and then, blam, there was some sort of error and (as always happens when Microsoft code encounters an error), the program had stopped and was now just sitting there with its thumb up its ass. I tried to read the error, but it was an impenetrable web of undefined mnemonic tech jargon interspersed with hexadecimal numbers.
After cleaning up the mess of half-copied tables that this error had left my new database in, I started the "wizard" again, and this time it made it further into the copy before choking on an error. It was becoming clear that the problem was my internet connection. I have Verizon DSL and it works okay most of the time. But every now and then there are glitches where, for a few seconds, it's 1988 again and I essentially do not have an internet connection. Most programs designed for the internet are aware of the internet's inherent unreliability and don't shit themselves the moment the connection is lost. They wait, they bide their time, and then, when the connection returns, they pick up where they left off. Not so the SQL Server Import and Export Wizard. Its behavior was sort of a two-for in that it showcased not one but two problems with Microsoft as an ongoing technological concern: they don't seem to understand the internet, at least the internet that most of us experience. And they don't understand the incredible superiority of a procedure that can function without having to be babysat. I'm sure the internet in Microsoft's corporate offices is rock-solid, and the SQL Server Import and Export Wizard hums along there without a problem. But in the real world, out where people are getting their DSL over decades-old copper occasionally strung between trees, people need software that can handle unreliable connectivity.
While I was babysitting SQL Server Import and Export Wizard (occasionally giving it the middle finger even when it wasn't crapping out), I watched a couple movies: Monster (which I'd seen before) and Basic Instinct II. Monster is a great movie. My favorite line in it is "Don't say nigger!" As for Basic Instinct II, I'd thought I was downloading the original Basic Instinct; the sequel is high-production but kind of a yawn after the opening scene. Still, Sharon Stone is an admirably-well-preserved cougar.
For linking purposes this article's URL is:
http://asecular.com/blog.php?100109 feedback
previous | next |
