We had a blizzard on Tuesday in Denver. Apr 24 and we got nearly a foot of snow out at the ranch.

We also lost power, which was a rude awakening. We had full laptop batteries, but no connectivity. I was taking kids to school and by the time I got back to work, the UPS's had run out of power, so I was stuck. I had time to grab a couple documents off my desktop before it died. Luckily my wife uses Cisco VPNs and has an air card from Sprint, so she can connect anywhere. I got the newsletter loaded and sent from her machine before we shut down. We couldn't charge the laptops, so we tried to use them as little as possible.

Why not go to Starbucks? We were snowed in. Literally. The kids bus made it to their stop and that was it. It got stuck there and was still there when I dug out with the tractor at 10 this morning.

So I got to Borders and worked a little, but had a scare. One of the newsletter processes is web based and it was failing.  So I hit the source file, edited it, and tried again. Still failed. I tried renaming a file, but it wasn't found. So I went to the backup web server thinking something had changed and tried there. Still it gave me errors.

Finally I realized that perhaps I had a DNS issue. I pinged the server and realized, by IP, that I was hitting the Denver server, not the UK one. I was about to start complaining to ZoneEdit, thinking they reloaded our zone from a backup for some reason, and then decided to check my hosts file. Sure enough I was pointing to the Denver server in there. I deleted that, restarted the browser and things were good.

Just an FYI, be very careful of using entries in the hosts file. If you wonder where it is, it's: /%system root%/system32/drivers/etc/hosts
   

    I saw Brian's post on Microsoft's post on post sp2-fixes. Say that 10 times quickly.

They do a good job explaining it and I'm actually releasing a link Monday to it so people can understand what's going on and what they should install to be current.

The one thing that I'm missing is that there's no explanation of why or how these problems surfaced. At least two of these fixes are just plain shoddy work, not bugs. At the very least, what the SQL Server community is missing is an apology for the hassles of installation and problems from Microsoft. I think it's appropriate and it would go a long way towards repairing the anger some people have.

Windows doesn't see 4GB. If you have a 32bit OS with 4GB of RAM, Windows can't see it all.

I saw this very interesting post from Hilton Locke at Microsoft on the issue. Apparently it's mostly hardware, depending on what you have, and an architectural decision that there are memory mapped IO reservations.

I'm not sure I understand it all, but it's an interesting post.

    On a recommendation, I picked up this book by Ralph Kimball. I remember it coming out years ago and I saw a speech by one of the co-authors, Margy Ross. She was great and I thought DW would be great. Then I got sidetracked into the OLTP world with a financial startup and let things go.

Years later it seems that warehousing is slightly more than a niche market, but since I'm heading to Seattle for the BI Conference, I thought I should learn a few things.

Chapter 1 is lots of terminology and trying to get you in the DW frame of mind. I'm not sure I'm completely sure of what it all means, but I'm plodding through it, trying not to go too fast and make sure I learn some things.

I wrote a small commentary on quality control today and I'm surprised it didn't get more reaction.

I'm not a great tester and I'm sure I'd have missed these things as well, but there's no excuse for Microsoft, with a SQL Server team of hundreds, to not regression check everything they know about. I mean how many machines and automated tests do they have? I think that they can do better and they got a little sloppy after a great release and first service pack.

Plus I thnk they're focused on the next version, due next year or the year after. I can't imagine it will come out in 2007 since we haven't seen a beta or CTP.

I wrote about Hot Fixes being inclusive of previous hot fixes. Someone questioned this and so I went back to Simon's blog and checked his source. He's a SQL Server MVP (and a great guy, I got to meet him at the Summit last year) and he got it from the MVP Summit.

I think it's controversial, mostly becuase I and many others, assumed that each hot fix was independent, but if you stop and think about it, as I have been doing, it makes sense. No one wants to maintain multiple code bases. It's hard and in vastly increases the chances for problems. Plus merges might be the least favorite thing for people to do, even less liked than bug fixes.

Think about it, you have SQL Server, this huge, multi-million lines of code software product. Suppose you have modules 1-5 to keep things simple. If there's a problem in module 2, you branch the code and start working on a Hot Fix. Now you also have work going on for the next service pack in Modules 3 and 4. You finish this patch and you have this:

Main branch               Hot Fix 1 Branch
  - Module 1                   - Module 1
  - Module 2                   - Module 2 patched
  - Module 3 (updated)   - Module 3
  - Module 4 (updated)   - Module 1
  - Module 5                   - Module 1

We have two branches and they can easily be merged at this point. Now suppose we're still working and someone finds a bug in Module 3. Now what do you do? You can branch again and get this

Main branch               Hot Fix 1 Branch              Hot Fix 1 Branch
  - Module 1                   - Module 1                   - Module 1
  - Module 2                   - Module 2 patched      - Module 2
  - Module 3 (updated)   - Module 3                   - Module 3 patch in progress
  - Module 4 (updated)   - Module 1                   - Module 4
  - Module 5                   - Module 1                   - Module 5

or work with your old branch

Main branch               Hot Fix 1 Branch
  - Module 1                   - Module 1
  - Module 2                   - Module 2 patched
  - Module 3 (updated)   - Module 3 patch in progress
  - Module 4 (updated)   - Module 1
  - Module 5                   - Module 1

But in either case, you have work to be done in merging. If this continues with 5 hot fixes, then the first scenario here gives you problems with many merges, 5 in all. And what if you need to make a second patch to Module 2. Not fix the first patch, but a separate problem? Then you'd have two merges in this module. Expand this to the hundreds of modules in SQL Server and you might have an idea of the problems.

The best solution is to perform builds using good code. Which means if you have modules that are works in progress, you ignore the current version and build with the last known good version. Which is what happens. So the best idea is something like this:

Main branch              
  - Module 1              
  - Module 2 (hot fix in progress)              
  - Module 3
  - Module 4
  - Module 5

then

Main branch              
  - Module 1              
  - Module 2 (patched)              
  - Module 3 (being updated, build with last known good for hot fix)
  - Module 4 (being updated, build with last known good for hot fix)
  - Module 5

then we find a problem with module 3

Main branch              
  - Module 1              
  - Module 2 (patched)              
  - Module 3 (being updated, work on new hot fix with current version. Maybe delay unti update is finished or do both at once)
  - Module 4 (being updated, build with last known good for hot fix)
  - Module 5

etc. It's still dicey when you have a problem with an area and a separate hot fix, but you're Microsoft. Throw a few more people at it to get it done quicker. Even comment out changes in code that are work in progress.