After upgrading a webpart from SharePoint 2007 to 2010 I got a exception from de search engine about the query format. I used the following code:

var sqlQuery = new FullTextSqlQuery(SPContext.Current.Site);
sqlQuery.ResultTypes = ResultType.RelevantResults;
sqlQuery.TrimDuplicates = false;
sqlQuery.QueryText = "SELECT Path, Title FROM scope() ORDER BY Title";

// Return the search results to a ResultTableCollection.
var results = sqlQuery.Execute();

When I debugged the code I found out that the ORDER BY clause was causing the problem. When I used a integer or date managed property in the order by clause the problem disappeared. I started investigating the options for text managed properties, in the properties for a managed property I found a new option:

The explanation for this option is:

To reduce storage requirements, new text properties are automatically treated as a hash which limits comparisons (including sorting) to equality/inequality.  Unselect this option to enable other types of comparisons (less than, greater than, order by).

When I enabled this option and started a full-crawl the problems are gone. In my opinion the error message should have been a bit more clearer.

Today I was working on a SharePoint 2010 project where the custom fields and content types where provisioned using a feature. After the feature was activated the custom fields and content types where provisioned in SharePoint, except the content type contained no fields. The element manifest file contained the following xml:

  <!-- Base Page -->
<ContentType ID="0x010100C568DB52D9D0A1...84E219954237AF3901"
              Name="Basepage"
              Description="Basepage"
              Group="Publishing"
              Sealed="TRUE"
              Inherits="TRUE"
              Version="1">
  <FieldRefs>
    <!-- Originating from MOSS -->
    <FieldRef ID="{b66e9b50-a28e-469b-b1a0-af0e45486874}"
            Name="Keywords" />
    <!-- Custom fields -->
    <FieldRef ID="{30607e4e-a3e1-4662-9766-56e1faedb875}"
            Name="AdminComments" />
  </FieldRefs>
</ContentType>

The ULS logs showed no errors and I couldn’t figure out what the problem was because the same element manifest file was used in SharePoint 2007. After the stripping the file I figured out that the xml comments were causing the problem. Now my element manifest contains the following:

<ContentType ID="0x010100C568DB52D9D0A1...84E219954237AF3901"
              Name="Basepage"
              Description="Basepage"
              Group="Publishing"
              Sealed="TRUE"
              Inherits="TRUE"
              Version="1">
  <FieldRefs>
    <FieldRef ID="{b66e9b50-a28e-469b-b1a0-af0e45486874}"
            Name="Keywords" />
    <FieldRef ID="{30607e4e-a3e1-4662-9766-56e1faedb875}"
            Name="AdminComments" />
  </FieldRefs>
</ContentType>

The content is the same except the comments are missing.

The problem

With the introduction of the October Cumulative Update for SharePoint 2007 I encountered a problem with the search box on multilingual sites. After the installation of the update the scopes dropdown list always uses the same scope display group. After investigation I found that the language of the root web is used to determine the scope display group.

The cause

This behavior was not present in the control prior to the October update, in the description of the update (KB975731) we found:

"All sites," "People," and "This site" search scopes are available only for English language sites. Sites that are written in other languages show only the "This site" search scope.

This explains that the control has been changed in this update.

The reason

Before the October Update the property ScopeDisplayGroupName is set in the constructor of the SearchBoxEx control:

this._ScopeDisplayGroupName =
    SearchCommon.GetLocResourceString(
        LocStringId.ScopeDisplayGroup_SearchDropdown_Name);

In the October Update this line of code has been changed to:

this._ScopeDisplayGroupName = GetScopeDisplayGroupNameDefaultValue();

This function uses the language from the root web is to determine the value for the ScopeDisplayGroupName property:

private static string GetScopeDisplayGroupNameDefaultValue()
{
    if (SPContext.Current != null)
    {
        while (SPContext.Current.Site != null)
        {
            CultureInfo siteCollectionCulture = null;
            SPSecurity.RunWithElevatedPrivileges(delegate {
                siteCollectionCulture = new CultureInfo(
                    (int) SPContext.Current.Site.RootWeb.Language);
            });
            return StringResourceManager.GetString(
                LocStringId.ScopeDisplayGroup_SearchDropdown_Name,
                    siteCollectionCulture);
        }
    }

    return SearchCommon.GetLocResourceString(
            LocStringId.ScopeDisplayGroup_SearchDropdown_Name);
}

The solution

For this website I want the value for the ScopeDisplayGroupName property to be based on the culture of the current web. To re-enable this functionality we updated our custom master page and added the following to the SearchBoxEx control:

<sharepoint:searchboxex runat="server" ...
 ScopeDisplayGroupName="<%$Resources:searchfix,ScopeDisplayGroup_SearchDropdown_Name%>" />

In the App_GlobalResources I added custom resource files with the correct translations for the resource key ScopeDisplayGroup_SearchDropdown_Name.