Robert on Software Development

Until about two weeks ago, I had no idea why so many developers were going ga-ga over Ruby on Rails. It wasn’t because I had a problem with Rails; in fact, I didn’t have an opinion at all. That’s the beauty of ignorance.

But as I started to delve deeper into SubSonic for my current project, I realized I needed to learn a bit more about the product that SubSonic is somewhat based on, specifically ActiveRecord. I figured, what better way to gain insight into how SubSonic works than to understand the genesis of the whole thing.

My foray into Rails development has been swift and deep. Now I get it: Rails lets you build Web applications very quickly, and it does that by requiring an adherence to a specific architecture that is governed by one person. It makes total sense.

That paragraph could be taken as a bash on Rails, but in fact, it’s not. I really like Rails. I really like that Rails is overseen and designed by one person (well, technically two). I think that’s a strong feature of the framework. In the .NET world, we don’t have that. .NET is meant to be general-purpose. It’s designed to let you create your own frameworks, and it gives you a million ways to do everything right and a million ways to do everything wrong. As I said to a colleague several years back, “.NET’s flexibilty is inflexible.”

Learning Rails is making me a better developer. It’s forcing me to learn new ways of doing things. I didn’t expect the exercise to have such an immediate and valuable impact. If I take nothing else away from this experience, I’ll at least have a much broader understanding of this business.

And MVC, of course.

Yesterday I installed Service Pack 2 for WSS 3.0 and MOSS 2007 on the two servers in our Development farm. I purposely did not follow the guidelines for upgrading SharePoint as I wanted to see what happened when I ran the installer. Since it’s a dev environment, there was no risk.

Long story short, the upgrade on both of my servers failed. Looking at the logs, I saw this:

[SPManager] [ERROR] [6/2/2009 10:44:16 AM]: The system cannot find the path specified.

That’s it. That’s all I had to go on. After some hemming and hawing and tearing my hair out, I figured out what the problem was. It’s not that the installer can’t find a path, it’s that the IIS metabase is pointing to a “dead site,” or a site defined in IIS for which the directory structure doesn’t exist. That fixed the problem on the database server.

On the farm’s front-end server, I got the same error, but I didn’t think that it was a problem with IIS.

My solution was to simply detach and reattach the content database, which is what Microsoft says to do in its best practices document for upgrading SharePoint.

If you choose to not follow the directions and end up with the “file not found” error, try this.

First, execute this command (replace the bracketed items with your details, without brackets of course):

stsadm –o deletecontentdb –url [http://example.com] –databasename [contentdbname] –databaseserver [databaseserver]

Don’t worry about the word “delete” in the command. It doesn’t actually delete your database. It just detaches it.

Once that’s done, reattach the content database via:

stsadm –o addcontentdb –url [http://example.com] –databasename [contentdbname] –databaseserver [databaseserver]

Now run psconfig to tie it all together:

psconfig –cmd upgrade –inplace b2b –wait –force

The configuration completed and everything worked.

My suggestion is to follow Microsoft’s SharePoint upgrade best practices document to the letter. This is the best way to head off these kinds of issues. And always make sure you back up your content and configuration databases before you upgrade. Few things are worse than rebuilding a SharePoint farm from scratch.