Subscription Query Language
User subscriptions consist of stored SharePoint Portal Server search queries. The Gatherer detects changes to documents and then notifies Index engine and Persistent Query Service (PQS) for indexing and subscription evaluation. There are differences between the SharePoint Portal Server SQL query syntax and the PQS query language. The following lists the differences:
PQS will match queries over properties that are not in the index but may be in the property store. This is especially important when using the ALL property. The ALL property finds properties that are in the index, and properties that are not in the index but may be in the property store. To work around this issue, use a group property containing ALL and assign all the properites that are not in the index with weight zero.
PQS is limited to the following rank restriction query syntax," where (Q) and Rank >|= number". The Rank property must be at the end of the query. Only "greater" and "greater OR equal" operators are allowed. Search allows any inequality.
PQS prefix queries such as "CONTAINS('"th*"')" will find noise words such as "the" and "this". Search does not include noise words. Search allows queries that contain only noise words such as "Contains('ISABOUT(the)')"). PQS rejects such queries.
PQS proximity queries will not find a document if the distance between the terms is more than MAX_DIST (currently the value is 50). Search includes documents with rank 0. For example, BestBetsKeywords, a multivalued property, contains terms A and B. The query "contains("urn:schemas-microsoft-com:publishing:BestBetKeywords", 'A near B')" would include the document in search with rank 0. PQS does not include such a document.
Ranks calculated by PQS and Search are not guaranteed to be identical. Exact ranks are difficult to compare because ranks are query and corpus state dependent.
In the case of relational comparison of multivalued properties, the default operator in Search is "SOME ARRAY". In PQS the default is "ARRAY" (the exact comparison). In the following Search query "urn:schemas-microsoft-com:publishing:BestBetKeywords" = ARRAY ['B', 'A']" will include a document contains ( BestBetKeywords = A, B ), but PQS will not.
PQS supports simple prefix or suffix wildcards in LIKE and MATCHES predicates. For example, LIKE(%position) or LIKE(exposit%) are allowed. However, LIKE(exp%tion) is not allowed. PQS supports a limited form of the MATCHES predicate. Full regular expression syntax, grouped and counted matches are not supported.
PQS will not accept a single character for prefix or suffix patterns. For example, A*, A%, %A are not allowed, but AB*, AB%, %AB are allowed. In addition, %AB% is not allowed where %ABC% is allowed.
The COALESCE_TABLE function is not supported for subscription queries.
The columns specified in the SELECT statement are not applicable to subscription queries, because the PQS does not return column data by way of the subscription notification. You can use ActiveX Data Objects (ADO) to obtain other columns for the subscription query results.
The PQS ignores ORDER BY clauses in subscription queries.
The SharePoint Portal Server Search SQL Syntax only supports NOT when it follows AND. The PQS supports NOT used in isolation. For example, … WHERE NOT "DAV:getcontentlength" > 1000 is not legal for search queries, but can be used in subscription queries.
All custom properties specified as columns in the SELECT statement or WHERE clause of a subscription query must be present in the index. That is, at least one document with that property must have been crawled. Subscription queries specifying custom properties that are not placed in the index or not retrievable will be rejected by the PQS. All the properties defined in the schema are always accessible, even if the catalog is empty.