Well funny thing happened these week, I wanted to create a (sub)web programmatically using the OM using a webtemplate. Nothing fancy here eh? :) Just what I thought so I build it and I wanted to test it and everyhing went ok. So I deployed on production environment, tested it there and then the problems came. It continually keep getting errors like 'cannot complete this action'. Things that did work :
1. The ID could be read via the OM
2. The title of the web could be read via the OM
Things that didn't work :
1. Kept getting 404's when I navigated to the site
2. Kept getting 'cannot complete this action' errors using the weburl and adding the /layouts/settings.aspx (or any other .aspx) urls
3. The navigation in WSS was broken, all the subsites could not be displayed.
4. Could not be deleted using the OM
5. Could not be deleted using STSADM
So what to do? Yes.. the one thing you should never do. Modify the database. It's unsupported by MS (default.aspx-scid=kb;EN-US;841057) as my mate Daniel also pointed out and told me to call support of MS to solve this issue. Although during our IM session I managed to fix it by modifying the record in the WEBS table and then I could delete the web using STSADM. The tricky part here is that you'd never know what happens in the future after this modification (although the records were gone after the deletion with STSADM, so technically speaking the modifications were not there anymore)
This brings me to the next thing I wanted to get of my chest and that is: Sharepoint developers/consultants must know what is going on in the databases. Having read the following blogpost SharePoint Database Growth Rates by Dave Wollerman about truncate the logfiles if the recovery model of the database is set to Full. By default the databases that are created by Sharepoint have the recovery model on Full. And why is that? I can't imagine why anyone wants to recover his/her Sharepoint database using the transactional logs since the database backup is probably the last backup/restore method you should use.
Therefore I always recommend setting the recovery model to Simple so you don't have to think about the transaction logfiles. Another benefit you get with this is better perfomance since the DMBS doesn't have to worry about creating logfiles. But to know all of this, just to let the DBA guys know how to configure, you have to get knowledge of SQL Server.
So to conclude this post: do some SQL Server training or even better get certified as MS SQL DBA (like I'm planning to be ;))