This project is read-only.
Search in MOSS, from a programmatic perspective, has come a long way in MOSS, specifically it is more robust (though could still be MORE robust), more bug free and therefore more suited for use as plumbing in applications. I have found it particularly useful to get over some of the scale restrictions SharePoint places on developers, and taken advantage of it to meet the need for aggregation.

In a recent project however I found myself writing this little piece of spaghetti code.

1: //Build the Select Statement
2: string baseQuery =
3: @"SELECT Title, Rank, Description, Created, Path, NumComments, NumViews, NumLinkbacks, Tags, Categories FROM portal..scope()";
5: //Set the base scope
6: string baseScope = @" (""SCOPE"" = 'All http://" strSiteURL.Host @"/ Blogs') ";
8: // Build the Where Clause
9: string baseWhere;
10: switch (tag)
11: {
12: case "":
13: baseWhere = @"WHERE " + baseScope;
14: break;
15: default:
17: baseWhere = @"WHERE CONTAINS (""Categories"",'""" + tag + @"""') AND " + baseScope;
18: break;
19: } get the idea.

I'm not proud of it, and couple of small bugs aside, was revisiting it to ensure it was "solid" (as if code like this could EVER be solid) when I threw in the towel, sick of writing code to write code every time I hit a project that needs to use search. There should be an easier/better way.

The result of my frustration is a tool that takes spaghetti code like this and turns it into:

1: MOSSSearch mossSearch = new MOSSSearch();
3: ArrayList Scopes = new ArrayList();
4: Scopes.Add("All http://" strSiteURL.Host @"/ Blogs");
5: mossSearch.Scopes = Scopes;
7: ArrayList returnProperties = new ArrayList();
8: returnProperties.Add("Title");
9: returnProperties.Add("Path");
10: returnProperties.Add("Rank");
11: returnProperties.Add("Description");
12: returnProperties.Add("Created");
13: returnProperties.Add("NumComments");
14: returnProperties.Add("NumViews");
15: returnProperties.Add("NumLinkbacks");
16: returnProperties.Add("Tags");
17: returnProperties.Add("Categories");
18: mossSearch.ReturnProperties = returnProperties;
20: WhereContains whereStatement = new WhereContains();
21: whereStatement.FirstWhereProperty = "Categories";
22: get the idea.

Which looks much more elegant to me (and I have improved it since this sample). Of course, actually creating the query in the first place is tricky too, and while a couple of test tools are available, I wanted to put one together that:
  1. Tested the SQL generated by the OM
  2. Output not only the SQL Statement, but the OM code as well, making using it as simple as cut and paste.
  3. Was inspired by the now missing in action tool MossQueryTool.exe written by SharePoint legend Steve Peschka (was on GotDotNet).

The result is the zevenseas SearchCoder and it looks like this:


Here you build your query graphically, when done you click on the "Build SQL" or "Execute Query" buttons which take you here:


Note the SQL Statement is generated, an on the C# SearchCoder OM Tab:


Other Free Solutions from zevenseas:
The zevenseas Team

Last edited Jul 24, 2013 at 2:09 PM by danielmc, version 15