Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I'm building a .NET Health Analyzer Custom Rule which checks a few vital signs of another custom application I have built, however if the application is also deployed on a server that is also hosting SQL Server AND the configuration database, there's a few checks I don't want to run (don't ask why, long story, mostly performance related). How can I determine via API where the Config database is actually located in SharePoint 2010?

share|improve this question
add comment

1 Answer

up vote 3 down vote accepted

This was nice quest for me. I will not ask why do you need this and I hope that you don't need warning like: Never mess with SharePoint databases directly!

I didn't found many articles on net covering this specific issue (no wonder when it is bad practice). The only one was 2007 related: Determining the Configuration Database in a SharePoint 2007 Farm. Check it out.

I came up with this piece of code:

    SPDatabase configDb = null;

    foreach(var service in SPFarm.Local.Services)
    {
        if(service is SPDatabaseService)
        {
            foreach(var instance in service.Instances)
            {
                if ((instance is SPDatabaseServiceInstance))
                {
                    var dbInstance = (SPDatabaseServiceInstance) instance;

                    foreach (var db in dbInstance.Databases)
                    {
                        if (db.GetType().ToString().CompareTo("Microsoft.SharePoint.Administration.SPConfigurationDatabase") == 0)
                        {
                            configDb = db;
                        }
                    }
                }
            }
        }
    }

So after few foreachs and few ifs you have SPDatabase object containing config database. I have tested it against my local SP and it works. I will not exclude there can be some issues in different environment and that there is maybe better way to do this.

Did I mentioned it before that even if you just take a look at hardware responsible for SharePoint database you can end up with some unexpected behavior?

share|improve this answer
1  
Nice 1, Op should definately keep the warnings in mind, SP DB's are to be considered "on loan" from MS, they are highly optimized and even a simple select on a highload content db can produce unexpected results and may result in your environment becoming "unsupported"... –  Colin Sep 9 '11 at 23:13
    
Well ok I can explain, what I'm doing is building a custom health analyzer rule that gauges performance. What I'm doing is running different benchmarks on SQL Server databases, including even more different benchmarks on the Config Database SQL Server. Everything is outta the box and I'm not tampering in any way with the content db itself. This is just to help me gain awareness of the overall environment. After I've tested this I'll mark for an answer or no :-) –  tekiegreg Sep 12 '11 at 19:48
    
+1 for the effort, very nice –  int32 Sep 13 '11 at 13:30
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.