Skip to main content
Mitratech Success Center

Search Parameters Syntax

The syntax used in Searching Client is described here.

Regular Search Field Syntax

The syntax used with Regular search fields, that is, search fields which are linked to Custom Field Types or to Index fields or to Audit fields, is explained below. (The syntax for Content Full Text search fields and Sub-search fields is described in Content Full Text Search Syntaxand Sub-Search Syntax.

Search parameter values are case sensitive is used to determine whether the search string is case sensitive. See “Search parameter values are case sensitive” for more information.

Wildcard Characters

A wildcard character is used to represent one or more characters having ‘any value’.

Text Fields

Wildcard character operators in Text fields are described in Table 211.

Table 211. Wildcard Operators: Text Fields

Wildcard Character

Meaning

%

Zero or more characters.
Example:

  • Williams% – any field values which start with Williams followed by zero or more characters such as Williams, Williams! and Williamson.

*

One or more characters.
Example:

  • Williams* – any field value that starts with Williams followed by one or more characters, such as Williamson, but not with Williams.

?

Exactly one character.
Example:

  • William? – any field value that starts with William followed by one more characters, such as Williams and William* but not with Williamson.


Date and Time Fields

Wildcard character operators in Date and Time fields are described in Table 212.

Table 212. Wildcard Operators: Date and Time Fields

Wildcard Character

Meaning

*

Wildcards the whole of the Date and Time field. Therefore, if the field has Time accuracy, the year, month, day and time are all wildcarded.

?

Parts of the Date and Time can be wildcarded as long as the Year has been specified.

Examples (assuming a DD MM YYYY configuration for a Time accuracy field):

  • ?/?/2009 ? – any time during 2009.
  • 1/10/2000 ? – any time on the 1st October 2000

It is not possible to wildcard the year of a Time Accuracy field. The text in the search field will turn red to indicate the syntax is invalid. For example 1/10/? ? (in a Time accuracy Date and Time field).

Assuming DD MM YYYY configuration for a Day accuracy field:

  • ?/?/2009 – any day during 2009.
  • ?/10/2009 – any day in October 2009.
  • 21/?/2009 – the 21st day of any month in 2009.
  • 16/?/? – the 16th day of any month in any year.
  • ?/7/? – any day in July in any year.

Ambiguous searches are not allowed. For example, in a Month accuracy search field, 07/? would not be allowed because it could mean the 7th day of any month or it could mean the 7th month in any year. However, the search July ? would be allowed because it clearly specifies the month of July in any year.

Comparison Operators

Wildcard character Range operators in Whole Number, Currency and Date and Time fields are described in Table 213.

Table 213. Comparison Operators: Whole Number, Currency and Date and Time Fields

Wildcard Character

Meaning

>

Greater than.
Example:

  • >1000 – any Whole Number or Currency value greater than 1000 or any Year later than 1000.

<

Less than.
Examples:

  • <1900 – any Whole Number or Currency value less than 1900 or any Year earlier than 1900.
  • < 20 September 2008 – any Date before 20th September 2008.

>=

Greater than or equal to.
Examples:

  • >=1000 – any Whole Number or Currency value greater than or equal to 1000 or any Year greater than or equal to 1000
  • >= 2000 – any Whole Number or Currency field equal to or greater than 2000 or the Year 2000 or later.

<=

Less than or equal to.
Examples:

  • <=1900 – any Whole Number or Currency value equal to, or less than, 1900 or the Year 1900 or earlier.
  • <= 20 September 2008 – 20th September 2008 or earlier.

Equality

The equality operator is valid for All field types.

Equality can be specified explicitly by prefixing the search term with an equals sign. For example, the following two search strings are equivalent:

  • 47 – Implicitly expressed: is equal to...
  • =47 – Explicitly expressed: is equal to...

Text Fields

If you wish to search for values in a Text field beginning with = < > or !, you must include the = prefix. For example:

  • ==a – searches for =a.
  • =<* – searches for any text beginning with <.
  • =!? – searches for ! followed by any single character.

image

Inequality and Inversion

The Inequality and Inversion wildcard character operators, valid for All field types, are described in Table 214.

Table 214. Inequality and Inversion Operators: All Field Types

Wildcard Character

Meaning

<>

Not equal to.
Examples:

  • <>Williams – not equal to Williams.
  • <>100 – not equal to 100.

!

Inversion or Not

!= and <> can often be used interchangeably.

Examples

  • !=Williams – not equal to Williams.
  • !=20/01/2000 – not equal to 20th January 2000 (assuming a Day accuracy Date and Time field and DD MM YYYY Locale)
  • !47 – not 47
  • !<47 – not less than 47
  • !20/01/2000 – not 20th January 2000

Negatives

Whole Number and Currency search parameter values can contain negative operators to denote numbers less than zero. (There are two negative operators allowed.)

Wildcard character Negative operators in Whole Number and Currency Fields are described in Table 215.

Table 215. Negative Operators: Whole Number and Currency Fields

Wildcard Character

Meaning

-

Negative number.
Examples:

-1 and -11.8

( )

Negative number (Accounting convention)
Examples:

(1) and (11.8)

Date and Time: Keyword Syntax

Date and Time fields support keywords to help simplify searching in Searching Client and when searching a Depot in Management Studio.

All Keywords must be prefixed by the # character (as shown).

When used in a Date and Time search field, the following keywords return the described results.

  • #today – returns results matching today’s date. Can only be used in Day and Time accuracy Date and Time fields.
  • #yesterday – returns results matching yesterday's date. Can only be used in Day and Time accuracy Date and Time fields.
  • #tomorrow – returns results matching tomorrow’s date. Can only be used in Day and Time accuracy Date and Time fields.
  • #thisyear – returns results matching the current year. Can be used in all accuracy Date and Time fields.
  • #thismonth – returns results matching the current month. Can be used in Month, Day and Time accuracy Date and Time fields. (#thismonth cannot be used with Year accuracy Date and Time fields.)
  • #thisweek – returns results matching any day of the current week. Can only be used in Day and Time accuracy Date and Time fields. By default, weeks start on a Sunday and end on a Saturday. (See “Configuration of Quarters and Weeks” for information on how to change the day of the week on which a week starts.)
  • #lastyear – returns results matching any day of the previous year. Can be used in all Date and Time fields.
  • #lastmonth – returns results matching any day of the previous month. Can only be used in Month, Day and Time accuracy Date and Time field. (#lastmonth cannot be used with Year accuracy Date and Time fields.)
  • #lastweek – returns results matching any day of the previous week. Can only be used in Day and Time accuracy Date and Time fields. By default, weeks start on a Sunday and end on a Saturday.
  • #q1, #q2, #q3, #q4 – returns results matching any day of the specified quarter (that is, 3 month period). Can only be used in Month, Day and Time accuracy Date and Time field. (See “Configuration of Quarters and Weeks” for information on how to configure the months making up q1, q2, q3 and q4.)

Quarters apply to the current calendar year. A year cannot be specified with a quarter keyword. (for example, #q1, #qtr2, #quarter4, etc.)

  • #qtr1, #qtr2, #qtr3, #qtr4 – same as #q1, #q2. #q3, #q4.
  • #quarter1, #quarter2, #quarter3, #quarter4 – same as #q1, #q2. #q3, #q4.
  • #now – Current date and time for Time accuracy fields. Current date for Day accuracy fields. Current month for Month accuracy fields. Current year for Year accuracy fields. See “More Examples of #now Syntax, below.

The above Keywords are not case sensitive.

More Examples of #now Syntax

#now can also be used with + and - days, weeks and years (depending on the accuracy of the search field).
Examples:

  • #now (+1 day) – today’s date plus one day.
  • #now (-3 months) – 3 months before today’s date.
  • #now (+10 years) – Today’s date plus 10 years.

When, for example, adding a number of days to #now to search on a Year accuracy Date and Time field, the days are added to the current date and time but only the year part of the result will be used in the search.

#now can also be used with < and >.
Example:

  • <#now – Any date and time before now.

There cannot be any spaces between the < and #now.

#now can also be combined with other search parameters.
Example:

  • >#now (-6 months) <#now – Any date between now and 6 months ago.

There cannot be any spaces between the > and #now or between the < and #now.

Configuration of Quarters and Weeks

Search users can change the default values for the #q1, #q2, #q3, #q4 and #thisweek search parameter keywords by adding following configuration to the DataStoreDSX Service, Management Studio, Indexing Studio, Searching Client and the Cheque Deposit Processing (if used) configuration files.

  1. Open the following files:
  • HitecLabs.DataStore.DataStoreService.exe.Config
  • HitecLabs.DataStore.ManagementStudio.exe.config
  • HitecLabs.DataStore.IndexingStudio.exe.config
  • HitecLabs.DataStore.SearchingClient.exe.config
  • HitecLabs.DataStore.ChequeDepositProcessing.exe.config (if required)
  1. Copy the following text:

<section name="HitecLabs.DataStore.Keywords.KeywordSettings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />

and paste it in the DataStoreDSX Server, Management Studio, Indexing Studio and Searching Client configuration files immediately below the line which starts with the text:

<sectionGroup name="applicationSettings"

  1. Copy the following text:

<HitecLabs.DataStore.Keywords.KeywordSettings>
        <setting name="FirstDayOfWeek" serializeAs="String">
                <value>Sunday</value>
        </setting>
        <setting name="FirstMonthOfFinancialYear" serializeAs="String">
                <value>1</value>
        </setting>
</HitecLabs.DataStore.Keywords.KeywordSettings>

And paste it in the DataStoreDSX Server, Management Studio, Indexing Studio and Searching Client configuration files immediately below the line which start with the text:

<applicationSettings>

  1. By default, the start month of the year value is 1 (underlined above). 1 is January, therefore quarter one runs from January to March of the current year. If you reset the month value to 6 and the current month is 5, the new quarter 1 will run from June to August of last year.
  2. By default, the start day of the week is SUNDAY (underlined above). Therefore the week is configured to run from Sunday to Saturday. If you reset the start day of the week value to MONDAY the week will be configured to run from Monday to Sunday.
  3. Save the files:
  • HitecLabs.DataStore.DataStoreService.exe.Config
  • HitecLabs.DataStore.ManagementStudio.exe.config
  • HitecLabs.DataStore.IndexingStudio.exe.config
  • HitecLabs.DataStore.SearchingClient.exe.config
  • HitecLabs.DataStore.ChequeDepositProcessing.exe.config (if required)
  1. Restart the DataStoreDSX Service.

Date and Time: Co-ordinated Universal Time

How Date and Time Fields are Stored

Date and Time fields are stored in Co-ordinated Universal Time (UTC). UTC is the same as Greenwich Mean Time (GMT) and Zulu Time. Therefore, if a document is stored on a system in France (which is 1 hour ahead of GMT) as 1st April 2010 09:00:00 and retrieved in England, the Item Stored Date and Time will be displayed as 1st April 2010 08:00:00.

Specifying Date and Time Searches in Zulu Time

Date and Time search fields values can be specified in Zulu Time. In the following example, the Locale is set to English (United Kingdom) and the computer has Daylight saving (or British Summer Time) enabled.

  • hh:mm:ssZ – specifies the Zulu Time Zone. For example, searching for:
    01/08/2012 00:06:00Z on a system in England during British Summer Time (BST) will retrieve results matching 01/08/2012 01:06:00. This is because 00:06:00 Zulu Time is equivalent to 01:06:00 BST.
  • hh:mmZ – the same as hh:mm:ssZ above, except :ss (the seconds part) is not specified.

Combining Search Parameters

For a field, any number of different search parameters can be combined with [OR] or [AND] operators.

  • [AND] – retrieves records containing all of the separated expressions
  • [OR] – retrieves records containing any of the separated expressions. When several values are selected from a Picklist, Searching Client automatically adds the [OR} operator between each picklist value.

Examples:

  • Williams [OR] Williamson – any result containing either Williams or Williamson.
  • Williams [AND] Williamson – any result where a search field is linked to multiple Index fields and both the value of Williams and the value of Williamson are returned.
  • >500 [OR] <100 – any result containing either values greater than 500 or less than 100.
  • >500 [AND] <1000 – any result containing values which are between 501 and 999, inclusive.

Also, a greater than and a less than comparisons can be written together with no operator in between; the appropriate operator is derived according to what is implied.

Examples:

  • <50 >500 – is equivalent to <50 [OR] >500 i.e. this will return all numbers: up to 49 and above 501, inclusive.
  • >50 <500 – is equivalent to >50 [AND] <500 i.e. this will return all numbers: from 51 up to 499, inclusive.

The [OR] and [AND] operators are not case sensitive, i.e. [OR] is equivalent to [or], [Or] and [oR].

Searching for Special Characters in Text Fields

To search for the following characters at the start of a Text field, enclose the search string in double-quotes:

  • ?
  • <
  • >
  • !
  • %
  • =
  • ~

For example, to search for <123>, enter “<123>” in the text search field.

The search string will be found only at the start of an index value. These characters will not be found in the middle or at the end of an index value. Therefore, “<123>” will not return 1<123> but it will return <123>1 (assuming Allow auto-wildcard is selected for the search field).

Content Full Text Search Syntax

The following section describes the syntax for content full text searching in Searching Client.

Content full text searching only applies to previously configured Content Full Text search fields. See “Content Full Text Searchable” for the configuration steps required for content full text searching.

When a Content Full Text search field is part of a Search Template with only Document-level fields, the content full text search returns Document-level search results. However, if the Search Template contains only Page-level fields, the content full text search returns Page-level search results. If the Content Full Text search field is part of a Search Template containing both Page- level and Document-level search fields, the content full text search is returned at the appropriate level depending on whether Page-level or Document-level search fields are used in the search. If no Document- or Page-level search fields are used in the search, or if both Document and Page-level fields are used in the search, then Page-level searches are returned.

Searching for two terms in a Content Full Text search field is equivalent to searching for the two terms with the [AND] operator.

Examples:

  • Mortgage Balance – Search for results containing both Mortgage and Balance.
  • Mortgage [AND] Balance – Search for results containing both Mortgage and Balance.

All search words must consist of at least two characters

  • Mortgage [OR] Balance – Search for results containing either Mortgage or Balance (or both Mortgage and Balance).

Logical AND binds more tightly than OR, so: Mortgage Balance [or] Credit will match documents containing both Mortgage and Balance and documents containing Credit.

Results matching the content full text search criteria are displayed in the font colour specified in the Style Sheet (see “Full Text Index Search Colour).

Inequality and Inversion

When used in Content Full Text search fields, the inequality and inversion operators allow you to specify the text you do not want to be returned.

Inequality and inversion wildcard character operators are described in Table 216.

Table 216. Inequality and Inversion Operators: Content Full Text Fields

Wildcard Character

Meaning

!
[and] !

Inversion or Not

!= and <> can often be used interchangeably.

Examples:

  • John !Doe – containing John but not Doe
  • John [and] !Doe – containing John but not Doe.

<>
[and] <>

Not equal to.
Examples:

  • John <>Doe – containing John but not Doe
  • John [and] <>Doe – containing John but not Doe.

It is not possible to only specify unwanted words in a content full text search. At least one wanted word must be included and the wanted word must come first.

Wildcard Character

Wildcard operator in Content Full Text Fields: % means zero or more characters.

Examples:

  • William% – all words beginning with William, for example, William, Williamson, etc.
  • Will% – all words beginning with Will, for example, Will, Willis, Williamson, etc.

A single % at the end of a search term is the only wildcard character supported by content full text search. It will also work within delimited strings. See “Using Double-Quotes in Search Strings” on page 892.

Proximity Search

Proximity search can be used with Content Full Text fields. [near] can be used between two search words to return results where the two words are within 50 words of each other in the same paragraph.

Example:

  • Mortgage [near] Credit – the word Mortgage within 50 words of the word Credit when the words are in the same paragraph.

Ignored Words

Full text indexing steps through documents and records (indexes) each word used in the document. However, the indexing engine does not index every single word in a document – in English, certain commonly used (‘noise’) words (such as the, on, a) are ignored.

The list of ‘noise’ words which are not indexed is determined by the language currently in use.

When a content full text search is performed, the entered words are searched for in the indexed words. Therefore, if the content full text search does not return the expected results, make sure you are not searching for commonly used ‘noise’ words. They will not be found, because the will not have been indexed. Table 217 shows the default list for commonly used English Language ‘noise’ words.

Table 217. English Language Search Word Exception List

about

can

how

of

the

were

after

come

if

on

their

what

all

could

in

only

them

when

also

did

into

or

then

where

an

do

is

other

there

which

and

does

it

our

these

while

another

each

its

out

they

who

any

else

just

over

this

will

are

for

like

re

those

with

as

from

make

said

through

would

at

get

many

same

to

you

be

got

me

see

too

your

because

has

might

since

under

a b c d e

been

had

more

should

up

f g h i j

before

he

most

so

use

k l m n o

being

have

much

some

very

p q r s t

between

her

must

still

want

u v w x y

both

here

my

such

was

z $

but

him

never

take

way

1 2 3 4 5

by

himself

no

than

we

6 7 8 9 0

came

his

now

that

well

_

Sub-Search Syntax

Sub-searching returns similar results to content full text searching. However, as it is a very processor-intensive type of search, it should be used for “one-off” searches only. If this type of search is required on a regular basis for a given Data Definition, content full text searching should be configured. See “Content Full Text Searchablefor the steps required to configured content full text searching for a Data Definition and associated Search Template.

Sub-searching can be performed when it has been enabled in the Search Template in

Management Studio. See “Allow text sub search.

When sub-searching is available and a search value has been entered in a regular search field or in a Content Full Text search field, the sub-search text box is displayed. Enter a value in the sub-search text box and click Start Search.

[AND] Search

To search for results which contain both wordA and wordB, use [AND]. For example:

wordA [AND] wordB

returns all results which contain both wordA and wordB (it narrows the search)

[OR] Search

To search for results which contain either wordA or wordB, use [OR]. For example:

wordA [OR] wordB

returns all results which contain either wordA or wordB (it broadens the search).

Sub-search results are displayed in the colour defined in the Style Sheet. See “Text Sub Search Colour” for more information.

Proximity searches cannot be performed in sub-searches.

There are no ignored words in sub-searches. That is, the words listed in the example of commonly used ‘noise’ words in Table 217, “English Language Search Word Exception List" can be searched for and, when found, highlighted in the sub-search results.

Using Double-Quotes in Search Strings

Search strings can be double-quote delimited to indicate the words or phrases which must match the text in the quotes. Double-quotes can be used around full-text indexing and sub- search text to search for all the text in the quotes. For example, when Account Holder is searched for in a content full-text search or a sub-search, pages with either Account or Holder are returned. When “Account Holder” is searched for in a content full-text search or a sub- search, pages with the text Account Holder are returned. That is, the words must be together and in the order specified.

When a Searching Client user wants to search for text which includes double-quotes, the double-quotes must be placed inside two more lots of double-quotes so DataStoreDSX understands the quotes are part of the search. For example, to search for “data”, the Searching Client user must enter “””data””” in the search field, but to search for 003827-11C "reference" number, enter “003827-11C ""reference"" number" in the search field.

When a value which includes double-quotes is selected from a picklist, the extra double- quotes are automatically placed around the value in the search field.

When a Searching Client user wants to search for text including double-quotes in a content full text search field or a sub-search field, they must put the extra double-quotes around the search text.

Also, if the user enters the text manually for a text search field (that is, they do not select the value from the picklist), they must also enter the extra double-quotes.

Examples:

  • “John Smith” – searches for results containing John immediately followed by Smith.
  • “John Smith*” – searches for results containing John immediately followed by any word beginning with Smith. For example, John Smithson.

Content full text searches are never case-sensitive. The parameter Search values are case sensitive (set in the Search Template) does not apply to Content Full Text fields.

For content full text searches, the words listed in the example of commonly used ‘noise’ words in Table 217, “English Language Search Word Exception List" on are also ignored inside double quotes. Therefore, in this example, searching for “Page 1” in a content full text search will locate all occurrences of Page, but the 1 will be ignored. Content full text searching for “Page 125” will locate all occurrences of Page 125, as only numbers 0–9 are ignored.

  • Was this article helpful?