Custom Search Scope Error - 'Your search cannot be completed because of a service error. Try your search again or contact your administrator for more information.'

When creating custom search scopes within MOSS 2007, be wary of mixing 'shared' search scopes and 'local' search scopes within a single display group. If you create a search scope at the site collection level (via the Site Settings > Site Collection Administration > Search Scopes menu), the scope will inherently be local. Note the absence of a check-mark in the 'Shared' column when viewing the site collection scope administrative page ([Site Collection URL]/_layouts/viewscopes.aspx?mode=site). The default 'People' and 'All Sites' search scopes are shared. Combining both a local and shared search scope into a single display will generate the following error within the search results if a user selects a combination of the 2:

Your search cannot be completed because of a service error. Try your search again or contact your administrator for more information.

To avoid this issue, either define your new search scope as shared by creating it within the SSP scope admin page ([SSP URL]/ssp/admin/_layouts/viewscopesssp.aspx?mode=ssp) rather than the site collection scope admin page. Or create a custom search display group that contains ONLY shared or ONLY local search scopes, so users won't be able to select both.

Posted on 4/30/2010 6:59:00 AM by sterlingt

Permalink | Comments (1) | Post RSSRSS comment feed |

Categories: MOSS 2007 | SharePoint 2007 Features


(Another) Method to Achieve Many To Many Relationships with SharePoint Lists

I stumbled onto this free tool recently and thought I would add it as an addendum to my previous posting Many to Many Relationships with SharePoint Lists. The CodePlex tool doesn't simply emulate a many to many relationship like the technique I documented within my previous posting, it actually exports the data to corresponding Sql Server tables which will enforce the relationships. I haven't had a chance to actually experiment with the tool, but the literature indicates it maintains an ongoing synchronization between the originating SharePoint lists and the Sql tables. Obviously there are some potential performance implications with regard to how and when the synchronization occurs, especially when dealing with large lists/tables.

Posted on 4/28/2010 6:41:00 PM by sterlingt

Permalink | Comments (0) | Post RSSRSS comment feed |

Categories: MOSS 2007 | SharePoint 2007 | WSS 3.0


Event Handlers/Receivers and (InfoPath) Form Content Types

The notion of being able to attach custom code to a slew of content type events is pretty thrilling. It's like a proverbial extra layer of cream cheese frosting in one's carrot cake, whereby custom behavior can be selectively appended to content types located across multiple libraries within a site collection.

Unfortunately, it appears (to me) that such event receivers are not supported by form content types, or those that are derived from them (such as InfoPath forms). To be clear, the registration of the event receiver to the form content type is successful () as I'm able to see it within the content type's SPEventReceiverDefinitionCollection. However, the overridden methods themselves (I tried the 6 basic ones ItemAdding, ItemAdded, ItemUpdated, ItemUpdating, ItemDeleted, and ItemDeleting) are never actually executed. Registering the same exact event receiver(s) to the form library itself (whose default content type is the aforementioned InfoPath form) will successfully execute the methods.

An inability to register event receivers to the content type of an InfoPath form will severely limit the scalable application potential of such custom functionality. The SDK makes no mention of this exception; neither does the 'Event Troubleshooting' article pertaining to SharePoint event handlers.

In addition, fields promoted to library column values from InfoPath forms (and consequently mapped to their corresponding XML file content) are ReadOnly within event receivers. Unfortunately there is no error attributed to this behavior, the field updates just 'silently fail' - a discovery I made after struggling with updating the values for many hours (and finally confirming the behavior here.

I've posted these issues to both the standard MSDN SharePoint dev forum as well as the MSDN Partner Break/Fix forum, and I'll update this posting with an information I obtain.

A couple of tools and tips that come in handy for working with SharePoint event receivers:
  • - This one for viewing the SPEventReceiverDefinitionCollection's of various objects to confirm successful registration.
  • - This one for both viewing existing registered event receivers, as well as performing the registration itself. (Note: The tool does not possess a 'Refresh' functionality so be sure to exit and application and re-start it when you've made changes to a receiver and you need to register the new version.)
  • I was never able to update event receiver functionality when using the stsadm 'UpgradeSolution' function, in spite of the fact that I could see the updated .dll within the GAC and I always deleted/re-registered the event receiver. Instead, I had to retract/delete the solution, re-add, re-deploy it, un-register the event receiver, and re-register it.
Ah - SharePoint...never a dull moment.

Posted on 4/28/2010 4:30:00 PM by sterlingt

Permalink | Comments (1) | Post RSSRSS comment feed |

Categories: MOSS 2007 | SharePoint 2007 | WSS 3.0


Cryptic Error When Deploying Visual Studio 2008 SharePoint Web Part Template

As a general rule, any development conundrum not easily solved via 'Googling-ing' is an immediate blog candidate. Recently when attempting to deploy a SharePoint web part template with Visual Studio 2008 ( in a new Windows 7 environment - I got the following rather cryptic error:
The content type text/html; charset=utf-8 of the response message does not match the content type of the binding (text/xml; charset=utf-8). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly. The first 1024 bytes of the response were...

To remedy the issue, do the following (Note: These instructions are for Windows 7 and the names may vary somewhat if you're working with Server 2008):
  • Navigate to the Installed Programs List
  • Select the 'Turn Windows Features on or off'
  • Expand the 'Microsoft .NET Framework 3.5.1' item.
  • Check the 'Windows Communication Foundation HTTP Activation' box and hit OK.
You should be good to go now.

Posted on 4/21/2010 11:18:00 AM by sterlingt

Permalink | Comments (2) | Post RSSRSS comment feed |



Making MOSS 2007 and WSS 3.0 play nicely with Adobe Acrobat PDF Documents

Seeing any of the following behavior when interacting with PDF documents within SharePoint?
  • The document could not be opened for editing. A Windows Sharepoint Services compatible application could not be found to edit the document.
  • There was an error opening this document. The file cannot be found.
  • Missing/blank icon for PDF documents
Add this line to one-liner to your DOCICON.XML document (C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML):
<Mapping Key="pdf" Value="pdf.gif" OpenControl="SharePoint.OpenDocuments"/>

And put the corresponding pdf.gif image in the SharePoint IMAGES directory (C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\IMAGES).

If users are annoyed by the in-browser method with which PDF documents are opened, that setting must be changed via the Adobe Reader application itself - Edit > Preferences > Internet, uncheck the 'Display PDF in browser' box.

Posted on 4/2/2010 6:34:00 AM by sterlingt

Permalink | Comments (0) | Post RSSRSS comment feed |

Categories: MOSS 2007 | SharePoint 2007 | SharePoint 2007 Features | WSS 3.0