We ran into an interesting behavior with FIM XPath search today. We have a client that has a hyphen character in their display names. A typical display name would look like “Test Person (Contractor – US)”.
We have a custom application that allows you to search for users by display name. Under the covers, this application talks to the FIM Service and issues a “contains” query for whatever you are searching. If you were to enter “Test Person” as your search term the application would generate the XPath query: /Person[contains(DisplayName,’Test Person’)] and in this case, would find the above user.
The problem we are running into is if the user tries to search for the whole display name. If you search for “Test Person (Contractor – US)” the XPath query becomes /Person[contains(DisplayName,’Test Person (Contractor – US)’)] and interestingly enough does NOT find the user.
It turns out that you can’t use the contains function if you are searching for a hyphen.
I took a look under the covers at the actual SQL statements the FIM service was generating based on the XPath and it appears that hyphens get converted to periods by the time the query gets to SQL.
The XPath Query:
/Person[contains(DisplayName,'Test Person (Contractor - US)')]
Gets internally converted to the SQL clause:
CONTAINS([valueOfProposition0].[ValueString],N''"Test Person (Contractor . US)*"'')
It also appears that having a period in the SQL contains clause prevents a match. Interestingly enough if you swap out the original hyphen with an open or close parenthesis, an asterisk, or an exclamation mark, they are not translated to a period by the FIM Service. (I didn’t test other symbols.) It also appears that within the SQL contains clause, the period and the exclamation mark cause the match to fail, but the open and close parenthesis and the asterisk are ignored and allow a match.
So my question is…
Is this expected behavior or a bug? The documentation for the FIM XPath contains clause says “Returns true if the value of the attribute specified in the first argument contains the second as a substring following a wordbreaking character, otherwise returns
false.” (http://msdn.microsoft.com/en-us/library/windows/desktop/ee652287%28v=vs.100%29.aspx) The documentation doesn’t mention anything about special characters,
but it does state that contains is looking for a substring match, which it doesn’t seem to be true if the substring contains a hyphen.
For now we will just strip out any hyphens that users type into the search before we send the string to FIM, but I am curious if this is a bug or not. We are running build 3508.
I am also curious to why if the FIM Service would strip out a hyphen and replace it with a period, why it wouldn't replace it with nothing or some other character that would not block a full text match.
Thanks
Rex