Search Wildcards
 |
The following topic only applies when your Search Mode preference is set to Simple. This is the default value. For information on Advanced mode searches, see Advanced Mode Searching.
|
Wildcard characters allow you to enlarge your search results by using inexact or variable search strings. This can be especially useful when performing database searches.
You can use wildcards for any search field that requires you to enter a text string. Wildcards can be used for both indexed and non-indexed searches.
• Spacing and Using Multiple Wildcards in a Keyword Search
• Using the Escape Character with Wildcards
• Unique Wildcard Behavior in Indexed Keyword Searches
The following wildcards are accepted:
* (asterisk)
The asterisk can be replaced by zero or more characters.
|
Name: ABC*
Results include the following object names:
• ABC
• ABC DEF GHI
• ABC–DEF.GHI
Name: *ABC
Results include the following object names:
• ABC
• 123ABC
• 123 456 ABC
Name: *ABC*
Results include the following object names:
• ABC
• 123ABCDEF
• ABCDEF
• 123ABC
|
? (question mark)
In most cases, the question mark can be replaced by only one character in attribute value or content of objects returned by the search.
|
Name: 12?4
Results include the following object names:
• 1234
• 12A4
Name: ??345
Results include the following object names:
• 12345
• AB345
Name: ABC 12?*
Results include the following object names:
• ABC 123
• ABC 123_45
• ABC 123 456
|
|
|
The examples above are entered into the Name field, and therefore illustrate a database search:  Keyword searches, specifically when using Windchill Index Search, would behave differently in some situations. For more information, see the section “Unique Wildcard Behavior in Indexed Keyword Searches” below. |
Spacing and Using Multiple Wildcards in a Keyword Search
You can use multiple wildcards in a single keyword or attribute value search. For example, entering p?* d?s* would return an object named “Part Design.”
However, if you enter more than one wildcard search term for a single keyword string, then the search fails. This is typically the result of an unnecessary space between your keyword terms.
|
|
When you perform a non-indexed search, using asterisk (*) in between strings accounts for space as well.
|
For example, consider an object named “PartDesign ABC-123” and the following keyword searches:
Keyword: ?a*De* ?BC*
◦ Indexed Search—Successful
◦ Non-Indexed Search—Successful
PartDesign ABC-123 is included in the search results for both types of keyword searches.
Keyword: ?a* De* ?BC*
◦ Indexed Search—Fails
◦ Non-Indexed Search—Fails
Both searches fail because the user includes a space between ?a* and De*.
Windchill processes ?a* and De* as two unique search parameters, which should return two unique strings (for example, “Part Design”).
However, “PartDesign” is only a single string. This creates a conflict that causes the search to fail.
Keyword: ?a*De*?BC*
◦ Indexed Search—Fails
The search fails because the user has removed the space between ?a*De* (“PartDesign”) and ?BC* (ABC-123). You cannot use wildcards to represent spaces between strings when performing an indexed search.
Windchill Index Search does not index spaces. Spaces are only used to split data into distinct keyword strings. For example, “PartDesign ABC-123” is indexed as the following strings:
PartDesign
ABC
ABC-
-123
123
This search attempts to use the asterisk character in De*?BC to represent “Design<space>ABC.” However, Windchill is not capable of correctly matching De*?BC with an indexed keyword string, because there is nothing in the index that could represent the space in “Design<space>ABC.” Instead, Windchill attempts to match ?a*De*?BC* with a single text string (for example, “PartDesignABC-123”).
◦ Non-Indexed Search—Successful
Windchill database searches interpret spaces literally, and therefore recognize the spaces that separate text strings. For example, “PartDesign ABC-123” is stored in the Windchill search database as the following strings:
PartDesign<space>ABC-123
PartDesign
ABC-123
When you perform a non-indexed search for an object name, your keyword term must account for every character in the value field, including any spaces. You can do this by either providing a literal keyword or by using wildcards.
Using the Escape Character with Wildcards
There are times when you must search for a string that contains a wildcard character. Enter a backslash character ( \ ) before a wildcard character to escape it.
When performing an attribute search or a non-indexed keyword search:
Enter a backslash ( \ ) before the wildcard character to search for the literal wildcard character in the search string.
For example, to search for an object with the attribute value 123?456, you would enter 123\?456. Otherwise, the search attempts to find objects where the question mark (?) is replaced by some other character (for example, 123X456).
When performing a keyword search with indexing installed and enabled:
If you enter a backslash ( \ ) before a wildcard when performing an indexed search, Windchill simply ignores both characters. Because Windchill does not index wildcard characters, there is no reason to perform a keyword search that includes a literal wildcard character.
For example, 123?456 is indexed as 123 and 456. Therefore, if you enter 123?456 as a keyword, the search fails to return the object because it is searching for a single keyword string in which the question mark is replaced by another character (for example, 123X456 or 1239456).
However, if you enter 123\?456 as a search term, the search ignores both the backslash and the question mark and then searches for 123 and 456. Your search results would include 123?456, but would also include any other objects that have both 123 and 456 as an indexed keyword. For more information, see Special Characters in Search Terms.
Unique Wildcard Behavior in Indexed Keyword Searches
At a basic level, there are essentially two kinds of indexed Windchill searches: keyword searches and database searches. For more information, see Rules for Keyword Searches.
The following rules apply only when Windchill Index Search is installed and enabled and you are performing a keyword search (a global search or an advanced search that uses the Keyword field):
|
Keyword Variable
|
Indexed Search Behavior
|
||||
|---|---|---|---|---|---|
|
Leading asterisk (*)
|
A leading asterisk (*) in the Keyword field or in a global search limits the search to indexed file content and to the mapped attribute values (Name and Number by default) and other object attributes values. . Without the leading asterisk, the keyword would be compared against all attribute fields.
For example, if you enter nitin* as a keyword for an indexed search, the results would include the following:
• Objects whose name or number includes “Nitin” or “Nitin” followed by one or more characters (for example, “NitinDesign.”)
• Objects with content files that include “Nitin” or “Nitin” followed by one or more characters (for example, “Nitin0123.”)
• Objects created or modified by a user named “Nitin.” (Or any other attribute value that might include “Nitin” or “Nitin” followed by one or more characters.)
Whereas if you enter *nitin, the search would return:
• Objects whose name or number includes “Nitin” or “Nitin” preceded by one or more characters (for example, “01Nitin”).
• Objects that have content files and/or attributes other than Name and Number which include the word “Nitin.”
For more information, see the advanced search use case scenario Keyword Searches Using Wildcards.
|
||||
|
Leading or trailing question marks (?)
|
A question mark (?) at the beginning or end of a keyword search string can be replaced by zero or one character.
For example, if you search for specification?, the results would include “specification,” “specifications,” and “SpecificationA.”
Similarly, ?end would return “end,” “bend,” and “send.”
|
||||
|
Spaces
|
When used in a single keyword search, a wildcard cannot substitute for white space between multiple strings.
For example, a search for product*specification would successfully return results for the following:
• product001specification
• product_specification
• ProductSpecification
However, it would fail to return the following results:
• Product Specification
• Product001 Specification
• Product%%Specification
|