Searching the Help
To search for information in the Help, type a word or phrase in the Search box. When you enter a group of words, OR is inferred. You can use Boolean operators to refine your search.
Results returned are case insensitive. However, results ranking takes case into account and assigns higher scores to case matches. Therefore, a search for "cats" followed by a search for "Cats" would return the same number of Help topics, but the order in which the topics are listed would be different.
Words and Phrases
| Search for | Example | Results |
|---|---|---|
| A single word | cat
|
Topics that contain the word "cat". You will also find its grammatical variations, such as "cats". |
|
A phrase. You can specify that the search results contain a specific phrase. |
"cat food" (quotation marks) |
Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase. |
Using Boolean Operators
| Search for | Operator | Example |
|---|---|---|
|
Two or more words in the same topic |
|
|
| Either word in a topic |
|
|
| Topics that do not contain a specific word or phrase |
|
|
| Topics that contain one string and do not contain another | ^ (caret) |
cat ^ mouse
|
| A combination of search types | ( ) parentheses |
|
Tuning: Designing keys for queries
Fully keyed queries typically offer the best performance. You can design keys to ensure that every query is fully keyed, although it may not be practical in all instances. Running all queries fully keyed requires defining a large number of keys, which in turn can cause performance degradation when using the add, update, and delete operations. In general, the Service Manager System Administrator should discuss query performance with the Database Administrator and tune the system accordingly.
Points to consider when designing keys:
- Design keys for the most used queries.
- You can optionally force users to issue fully keyed queries by not allowing partially keyed and non-keyed queries.
- Specify the fields that are most commonly used at the beginning of the key in the query.
- Specify fields that have many possible values at the beginning of the key. A key with a Boolean field at the beginning is inefficient, unless the majority of your queries return only a small number of records. For example, flag=true in the probsummary table eliminates 90% of all records.
- Do not use the same field in multiple keys. If you update a record and then change the value of that field, update all of the indexes that contain that key.
- Do not define more than 25 keys for one file. The more keys defined for a file, the more time is required to add, update, and delete records in that file. Likewise, if you define too few keys, the operations run faster but the searches on the individual file run slower.
- There is no specific rule of how many keys you should define for a file. Logical consideration of these facts and your specific work environment are the best decision-making factors.
Related topics
Nonkeyed queries
Partially keyed queries
Stored queries
True queries
Key type definitions
Tuning: Fully keyed queries
Tuning: Improving query speed
Tuning: Key selection algorithms
Tuning: Number of fields in files
