The original point of the article was essentially about using the SQL Server 2005 client tools to manage SQL Server 2000 instances. Based on my experiences of the past few months, I say that doing this is a big mistake.

The SQL Server 2000 client tools were for all intents and purposes "second generation" -- 2.0 versions, revamped and revised from SQL Server 7.0. From what little I've heard, the SQL Server 2005 client tools were rewritten from the ground up in .Net 2.0 (which some say explains why they're so darn slow). Thus: on the one hand, no way could they recreate *everything* in their brand-new rewrite on the first go; on the other, maybe the original (C++?) coders cashed in their stock options, and MS had to recruit a fresh batch of college students.

[I'll site the interview by Rick Chapman with Joel Spolsky that he included in the back of his  (Champamn's) book "In Search of Stupidity" for why the "rebuild from the gound up" trick is so very dangerous. Can't find it online, alas.]

Anyway, my point and strong recommendation is this: manage SQL 2005 instances with the SQL 2005 client tools, and manage the SQL 2000 instances with the SQL 2000 client tools. It makes no sense to manage 2000 in 2005 *if* you have no 2005 instances to support as well. (And if I did, I'd have both sets of client tools available, if only to maintain my sanity.)

   Philip