Ranjan Banerji

Often one has to write code to loop through all of SharePoint to make some sort of a sweeping change. Making such changes directly in the database is a bad idea and is not supported by Microsoft. So the best way to do so is to use the SharePoint WSS object model. SharePoint Harvester hopefully will make it easier to do so by providing a recursive traversal of a SharePoint application firing events when a site, list, item etc is found.

The SharePoint harvester code is really simple and can be accessed from http://www.codeplex.com/SharePointHarvester.  I am not going to start discussing the code itself.  Simple recursion and when webs, lists, items, etc are found it calls a virtual method and fires an event.  This way a user may choose to inherit from this class and override some methods or they can subscribe to relevant events.

So for example if you want to turn off versioning for every list in on every site in an application.  How would you do that?  You could go through the UI and browse to each site and each list and then turn off versioning for that list.  What if you had 500 sites each with 10 lists.  That is a lot of work.  Using SharePointHarvester you could do something like:

public void TurnOffVersioning() {
    SiteHarvester siteHarvester = new SiteHarvester();

    siteHarvester.Url = "http://some.sharepoint.url";
    siteHarvester.Recursive = true;

    siteHarvester.ListFound += new ListFoundHandler( siteHarvestor_ListFound );
    siteHarvester.RunHarvester();

}

void siteHarvestor_ListFound( object sender, ListFoundEventArg e ) {
    e._list.EnableVersioning = false;
    e._list.Update();
}

You do not have to run this code for the entire application.  The URL you provide could easily have been for some sub site, for example:

siteHarvester.Url = "http://some.sharepoint.url/SomeSite/SomeSubSite";

Harvester will now only get lists for SomeSubSite and all its descendant sites.  As you can see, it makes life a lot easier instead of having to write the recursive code over and over.  More complex situations can now be handled.  For example what if you wanted to check-in all images that have been checked out across the entire application, or delete versions of all images because you are suffering from DB bloat.

More examples will follow.

In SharePoint 2007 when you create an application you specify the name the database to use.  Most people, therefore, conclude that an application will use one database.  This is not necessarily a very scalable idea.  But then you will often hear that an application can have more than one database.  The more commonly heard statement is that a Site Collection can have its own database.

True, very true.  Each site collection under an application can be made to have its own database.  But how?  When you create a site collection you are never asked which database to use or if a new database needs to be created.

Well our friends at Microsoft have made this in a very confusing process.  But here goes:

• Let's start with creating a new application.  When we create the application we tell it to use the following database: WSS_CONTENT_1
• Now create a site collection (SC1) under this application and a few sites under the site collection.  All the sites will use the WSS_CONTENT_1 database.
• Now go to Central Administration, Applications, Content Databases.  Select WSS_CONTENT_1 and change its status to "Offline".
• Now under Central Administration, Applications, Content Databases create a new content database WSS_CONTENT_2.  Make sure its status is "Ready".
• Now create a new site collection SC2 and create a few sites for SC2.  They will use WSS_CONTENT_2.
• Now create yet another site under SC1.  It will use WSS_CONTENT_1.  This is despite the fact that WSS_CONTENT_1 is "Offline."

So what we have achieved through this roundabout way is a content database for each of our site collections SC1 and SC2.  It would have been a lot better if when creating a site collection in Central Admin one was asked if a new database is to be created or if one wants to use an existing database.

In the Central Administration, Application Management, Content Database module setting a database offline means that from this point on no new site collection will be created in this database.  However this database is still usable and new sub-sites under an existing site collection can be created.  One has to be very careful to take each content database offline once a site collection has been created to prevent any other site collection from being created to use it.  This way you can make sure that each site collection has its own database. 

BTW, the same can be achieved via an stsadm command:

stsadm -o createsiteinnewdb -url http://your.application.com/SiteCollection -owneremail owner@application.com -ownerlogin Application\Owner -sitetemplate sts -title “Title” -databaseserver servername -databasename WSS_Content_Somename

Why would you want a site collection to have its own database?  Well that depends on what you are building and is a subject that is best handled in another post.