The advanced search box is available for more specialized queries filtering different scopes, properties and free text clauses.
The standard advanced search web part uses FREETEXT SQL clause for “find document with…” keyword terms. Below samples are shown of how keywords are translated:
All words (AND)
Keywords: john smith
SQL clause: freetext(defaultproperties, ‘+john +smith’)
Keywords: “john smith”
SQL clause: freetext(defaultproperties, ‘”john smith”‘)
Any words (OR)
Keywords: john smith
SQL clause: freetext(defaultproperties, ‘john smith’)
Note, this is how the hidden object submits the OR query by using the freetext(defaultproperties, ‘john smith’) – However, if the query is done using the Search WebService it will interpreted it as an AND query. This is most likely because the hidden object uses KeywordInclusion.AnyKeyword on the FullTextSqlQuery object.
None of words (NOT)
Keywords: john Smith
SQL clause: freetext(defaultproperties, ‘-john -smith’)
The different clauses work across the different keyword inputs, fx:
None of words
SQL clause: freetext(defaultproperties, ‘+john -smith)
“Add property restrictions…” allows the user to select filtering on individual properties, like author, title or description. The properties will change depending on the selected result type. The available properties for All results are the following:
Last Modified Date
Last Modified by
You can add your own custom properties by 1) mapping the crawled property to a managed property and 2) changing the result type xml of the advanced search web part to include the property. Using the result type xml you can also add new types of results for specialized content types.
Even though the user interface says “contains” in the operator drop down, it is important to note that that it actually doesn’t use a CONTAINS SQL clause. Instead it uses a LIKE statement, for example a property search on author is translated to the following clause: (Author LIKE ‘%john%’).
None of the search component use the CONTAINS clause. That means that asterisk (*) cannot be used as wildcard operation in any of the standard search web parts and UI.
Note, adding property restrictions to the query will most like slow down the query.
As a final option the advanced search gives to the possibility to filter results based on either language, item type or site scope.