SQL

This build replaces build 2162, and has a few 64-bit specific fixes in it. If you are running SQL 2000, probably a good idea to stick this on your server.

KB 894905

You'll know that you are running the most up to date version of SQL 2000.

If you've been getting a lot of "Unable to read local eventlog (reason: 87)" entries in your event log with SQL 2005 RTM from the Alert Engine of SQL, you'll be happy to know this has been fixed in the new build.

Some installs never have it show up, others have it fill up the event logs. Strange little bug but I'm glad it is gone.

You can download it from here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=39ebef74-1c29-49fe-8221-c94f2b52f6c6&DisplayLang=en

A great example of how not every tool fits every scenario. It gives a lot of insight into the 'why' and 'why nots' of various technologies.

http://blogs.technet.com/mscom/archive/2006/02/13/419406.aspx

Their blog is usually a good read anyway. If I didn't like my house, land, and job in Michigan right now, I'd probably want to be working in that department. It is the type of stuff I love to do. Only thing that might eclipse that is the stuff that goes on in the EEC.

Why? You only need licenses per physical CPU. That is a big cost saving.

More info here: http://www.microsoft.com/sql/howtobuy/multicore.mspx

Specifically:

Microsoft has been driving thought leadership in this area by charging the same amount per processor, regardless of how many cores are in the processor. Microsoft was the first database vendor to make this announcement, in October of 2004, and continues to be the only vendor to date that has taken this position. This strategy is based on the belief that multicore processors are a natural extension of Moore's Law (that the number of transistors on a chip doubles about every one to two years), and that the benefits should be passed on directly to customers.