Bad Habits to Kick : Using ancient copies of Books Online
In my last post in this series, I talked about inconsistent table aliasing. Today I was reminded of another behavior that DBAs and developers alike can be lazy about: keeping Books Online current.
There are always going to be mistakes in any set of documentation, and this is especially true with the scope of SQL Server Books Online. Thankfully Microsoft is committed to correcting mistakes, omissions and ambiguities (I have been the driver of several corrections). So, inevitably, there will be updates both to the version you have installed on your workstation and to the online version.
Unfortunately, I would be that a large percentage of you who use the local version of BOL, are still using the documentation that came with the RTM version of the client tools you've installed. It really is important to keep your client tools up to date with service packs, and it is equally important to keep your local copy of Books Online current. This will ensure that you don't make decisions or statements based on false or ambiguous information that has since been corrected (as I believe happened recently in the comment thread for my previous "bad habits" post).
I know that some people want to keep multiple copies of the "old" documentation around for comparison, research, trivia, nostalgia, and who knows what else. My suggestion for this is to keep the original copies in a virtual machine, and make sure that the copies of BOL that you will invariably use for active development on your primary workstation(s) — and on servers where BOL is installed — are up to date.
This blog post explains that web updates will be pushed every 4-8 weeks. It also explains why you may always want to use the online version of Books Online, at least when possible (some non-critical updates, it seems, will never make it into the local version):
So what can you do to make sure you're up to date? Well, check the title bar of the Books Online document viewer application. If it doesn't have a (Month Year) designation in the title, then you are probably at RTM and should apply an update, or resolve to use the online version.
Download Local Copies
The most recent version of SQL Server 2008 Books Online can be found here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=765433f7-0983-4d7a-b628-0a98145bcb97
The downloadable version of SQL Server 2008 R2 Books Online is here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=c18bad82-0e5f-4e82-812b-5b23e5d52b9c
And for SQL Server 2005, you can get the latest version of Books Online here (I wouldn't expect any more updates at this point):
Finally, for SQL Server 2000, the latest version is here (and again, do not expect more updates):
Use Online Versions
Here are the links to using the online versions of SQL Server Books Online:
SQL Server 2008 R2 Books Online
How could Microsoft make this better?
It would be nice if service packs automatically included the latest updates to Books Online. There are three barriers to this: (1) it makes the download bigger; (2) it is tough to synchronize service pack releases with the much more frequent Books Online updates; and (3) most people never apply service packs to their workstations, which is where the outdated versions of Books Online are being used. So, I think this is unlikely to happen. We had some ideas in a comment thread to one of Tibor Karaszi's blog posts, but those ideas never really materialized beyond that.
Summary
Until Microsoft comes up with a better way to push content updates to all users, I advise you to watch the above blog and update sites for new releases of Books Online.
Saggi, 100% agreed, I stated this: "It really is important to keep your client tools up to date with service packs […]" I was hoping this would be inferred as SSMS, client connectivity components, etc.
Hey Aaron,
You nonchalantly mentioned an even worse habit (imho) onto this post – not applying service packs to sql clients. service packs patch ssms and client tools as well.
So true. One of the biggest mistakes I ever made as a DBA (looking sheepish here) was because a hyperlink in some SQL Server 2000 documentation pointed to the wrong procedure. It was about cluster maintenance, and it was a big deal. That's all I will say :-).