A query defines the data to be retrieved from the database. It consists of a source, a selection, detailed and summary filters, and a dimension Information. Query hints can be supplied. A query does not define the structure or presentation of the retrieved data. The source defines the metadata upon which the query is based. The source will mostly be a model reference, but we will support referencing an other query as well. In both of these two case, all other queries in the querySet are implicilty part of the source. In addition, we will support direct query against an underlying data source technology like MDX or SQL that can be encoded within the specification. In addition, the source could be the outcome of a query operation involving two or more queries, the result of which is a projection of query items that can be used by the selection and queryResultDefinition. Lastly, the source could be the outcome of a join operation between exactly two queries. The selection identifies the metadata elements upon which the query is based. This is analogous to a projection from the source. The dataItem represents a set of data values or members. It is described by a metadata reference or by directly referencing member data. defines the set of data values or members that represent the dataItem. Defines the EBNF for the expression syntax allowed for queries. unique name (identifier) of the item within the scope of a query's selection a displayable caption of the item. If not specified, the name attribute of the data item will be used as its label the not applicable value is used for V4 cube items converted to V5 selection items. V4 cube item aggregation has the equivalent V5 rollup aggregation. In this case, the aggregation is done only on rolled up values and hence QF uses only the rollupAggregate attribute value. The aggregate attribute value is not applicable. WO1478. This attribute ensures that the correct aggregates for xtabs are computed by OQP. This attribute when set to true indicates that if this member definition on an edge intersects with a calculated member then the resulting cell value should be N/A. Specifies the solve order for this calculation. If no solve order is specified then the solve order will be follow the default rules that the server uses to determine solve order. Dimension information augments the selection. It is optional and is specified by an advanced query author when: 1. There is no dimension information available in the source. 2. The author wishes to override the dimension information in the source. 3. The author wishes to extend or restrict dimension information in the source.The intent of this information is not to define the presentation of the information, but to help query planning. In other words it can be considered a form of hint. If the dimension information is omitted then dimension information will be used from the source if available. If not available, it will be defaulted by the Query Framework. a collection of dimensions A dimension represents a collection of member elements within the same logical domain that can organize a set of data; without levels, there are no relationships between the elements other than their relative position within the collection.For example, a collection of months makes up a “time” dimension. A member is an item within a dimension that represents an occurrence of schema data. For example, “Proctor and Gamble” could be a member of a “Manufacturer” dimension.A dimension may have members with non-unique names, but all members must have a dimension-wide unique identifier.All members have at least a single parent; members in a network hierarchy may have multiple parents. A hierarchy is an organization of a dimension’s members into a logical tree structure, with each member having one or more “parent” members and an arbitrary number of “child” members. The root of a hierarchy has no parent, and leaf members have no children. A dimension may contain multiple independent hierarchies. The purpose of having multiple hierarchies is to provide alternate representations of a dimension’s data and ways of navigating it. For example, a Time dimension may have a regular calendar hierarchy and a fiscal calendar hierarchy. The first hiearchy defined in this collection is the default hierarchy. describes how the levels in a dimension are logically ordered. A member hierarchy is an organization of a dimension’s members into a logical tree structure, with each member having one or more “parent” members and an arbitrary number of “child” members. a collection of facts that form a fact or measure dimension that is considered as a special dimension. facts, also known as measures, are special kinds of members whose values are a certain business measurement, such as sales or inventory levels. Facts are the central values that are aggregated and analyzed. Facts form a measure dimension. A measure may also represent a formula, which involves other measures and/or members from different dimensions. Such measures are referred to as calculated measures. Sales, Revenue, and Quantity are common examples of facts or measures. NOTE: This element is deprecated and will be ignored in BlackSea. Each measure in a factList may only have values associated with particular dimensions or with a subset of levels within a dimension. For example, a measure representing inventory count may not be defined relative to a salesperson dimension and may only have values available at the month level and higher in the time dimension.The Measure_Scope metadata object provides a list of the dimensions, hierarchies, and/or levels that define the scope of the measures within a cube. a collection of levels that represent an arbitrary kimball star schema a set of members with a predifined set of similar characteristics. For example, the members “Year 1999” and “Year 2000” in the “Time” dimension form a year level, while the corresponding quarters form a quarter level. a key is a list of member set refs that together, uniqely identify members of the level. a collection of level attributes. Attributes (also referred as “properties”) are auxiliary information associated with members of a level. Attributes can be used for narrowing a search scope within level members or to provide additional information about members.“Address”, for example, may be an attribute of a store dimension at the “Store Region” level. A reference to a selection dataItem that represents the caption for this level. The caption is a special level attribute that represents the name of the level members, usually usefull for reporting. a reference to a level within a dimension a list of member expressions. the list is interpreted as a tuple of members. an arbitrary set expression resulting in members from a single hierarchy of a single dimension. a reference to another query defined in the query set or a query subject when used by FM to plan a relationship SQL. Defines the EBNF for the expression syntax allowed for queries. The filter expression must evaluate to a boolean a collection of calculated members. Defines filters that are applied to the incoming data stream of the query. This filter is applied before any summarization. {required} When optional, this filter will be applied only if all the parameters referenced by the filter expression have been provided with values. If the filter expression does not refer to any parameters, then this filter will always be applied. When prohibited, this filter will never be applied, which is useful for testing and authoring purposes. Default: "required". {false} Specifies that when "false", this condition will be applied to detail database rows from the tabular result set prior to aggregation and summarization. Any reference to a fact (aggregate) item in this expression will be interpreted as the individual database value before it has been summarized. When "true", this condition will be applied to the summarized rows; that is, after one or more detail rows have been aggregated into one summary row. Any reference to a fact (aggregate) item in this expression will be interpreted as the aggregate value of the summarized row(s). This attribute has no effect upon references to non-aggregate items, nor is it effective when automatic summarization is disabled (see "autoSummary" attribute of the selection element). This attribute has no effect in all cases for OLAP data sources. Defines filters that are applied to summaries computed by the query Refers to a resultSet level (a QRD group, or a diminfo level in the query or in the model or a dimensional data source level) to which this filter is applicable. Multiple references indicate an intersection of level groups from seperate edges (one level per edge); the overall or root level is assumed for omitted dimensions in the case of a dimensional model. Item references in the filter condition are scoped automatically to the indicated level(s). A filter without level specifications is applied to the overall level of the result set. {required} When optional, this filter will be applied only if all the parameters referenced by the filter expression have been provided with values. If the filter expression does not refer to any parameters, then this filter will always be applied. When prohibited, this filter will never be applied, which is useful for testing and authoring purposes. Default: "required". hints specific to this query within the querySet. When enabled, query returns NULL value for any item that encounters a divide by zero error. The autoSort hint does not return an error. It affects execution of a request as follows: If set to true, then a sort will always be generated in Cognos SQL or for crosstab queries in the request sent to MDDS, even if no explicit sorting is specified in the request. If false, then sorting will only be generated if explicitly specified in the request. If set to minimal, then for non-crosstab queries sorting is not added for the lowest level. Determines what level keys are sorted. The autoSort governor does not return an error. It affects execution of a request as follows: If set to true, then a sort will always be generated in Cognos SQL or for crosstab queries in the request sent to MDDS, even if no explicit sorting is specified in the request. If false, then sorting will only be generated if explicitly specified in the request. If set to minimal, then for non-crosstab queries sorting is not added for the lowest level. autosort Disabled: keys of the levels are included into sort list only if there is explicit sorting specified in the query. autosort Enabled: keys are included into sort list. autosort Minimal: keys are included into sort list except lowest levels of the query spec in 1D case and if no DetailDA present Do not add default sorting to the lowest level of a one-dimensional query in Minimal autoSort mode when there is no detail data databaseOnly, limitedLocal. The queryProcessing hint will return an error if UDA has to do any local processing for the generated Cognos SQL and the governor was set to DatabaseOnly. If the generated Cognos SQL contains an AT clause, or if the request accesses more than 1 database, then the queryProcessing governor will be set to LimitedLocal for the execution of the request. Queries are rewritten such that all the query processing is performed on the database, and the none performed on the client. Queries are rewritten such that little, and possibly none, of the query processing is performed [locally] on the client. The outerJoinAllowed hint will return an error if the generated Cognos SQL contains an outer join and the governor value is false or deny. A governor value of 0 means no error is returned. The crossProductAllowed hint will return an error if the generated Cognos SQL contains a cross product and the governor value is false or deny. A governor value of 0 means no error is returned. The suppress hint will control whether suppression is done to the query results. This hint does not return an error, but it impacts the generated SQL. Specifies where to compute aggregates. The Extended setting means that the aggregates are computed using an extended aggregate operation. The Database setting means that aggregates are computed by the database software. The Local setting means that aggregates are computed by the data retrieval software in the report server using a running aggregate. How to get the rollup processing setting: 1. governors have highest priority 2. derive it from the datasources in the model. 2a. If there is only one datasource, use its setting 2b. If there are more than first set it to database rollup, which will be adjusted later on in the FinalizeRollupAggregateProperties method The maxRowsRetrieved hint will return an error if the number of rows retrieved from the underlying database system exceeds the governor value. A governor value of 0 means no error is to be returned. The maxTablesPerQuery hint will return an error if the number of tables in the generated Cognos SQL exceeds the governor limit. A governor value of 0 means no error will be returned. The maxQueryExecutionTime hint will return an error if the time to open the cursor of the request associated with the generated native command plus the time to fetch the first row, exceeds the governor value. The value is given in seconds. A governor value of 0 means no warning is to be returned. This governor is not for the total time to execute the whole request; just the cursor open time + time to fetch the first row. If the total time of the request exceeds the governor limit, but the cursor open time + time to fetch the first row, is still within the governor limit, then no error will be returned. This is the case many times when lots of rows are returned. To restrict users from fetching too much data, the maxRowsRetrieved governor can be used. The maxTextBlobCharacters governor returns an error if the number of characters read for a text blob exceeds the governor value. A governor value of 0 means no error is returned. Specifies whether to send a request to the database using an SQL WITH clause. When set to Yes, and if the database supports WITH clause, a WITH clause request is generated. When set to No, or if the database does not support WITH clause, a request using dereived tables is generated. use alternate (V4) query semantics in cases where they differ from Cognos 8 BI Query rules Controls whether queries are run concurrently or sequentially. When making a call do not send this query to QFW to retrieve parameter information. Either this query does not contain parameters or the definition of the parameters exists in another query. Join syntax in Cognos SQL can either use explicit joins (a.k.a. sql99 join syntax) or implicit joins. explicit - select a.a, b.b from a inner join b on ( a.c = b.c ) implicit - select a.a, b.b from a, b where a.c = b.c There are a number of situations in which using explicit join syntax will cause the query to execute up to 200 times faster. However there are also a number of situations in which using implicit join syntax will cause the query to execute 50 times faster. If not specified, RQP will use the setting in the cqeconfig.xml file Describes the set structure of this query. If this is not defined it is assumed that each dataItem defines an unrelated set. a model source. The source for this query will be the FM model specified in the modelPath of the querySet A SQL query against a relational data source. The text of the typed-in sql. It is assumed to be appropriate for the type and data source. If it is not, the query may fail, or produce unexpected results. This contains the metadata returned for the typein sql. The queryMetadata is optional and is not required in order to execute the query. Specifies the level of flexibility the system is allowed in optimizing the query text from this element, before presenting it to the data source. Cognos SQL can be optimized by the system and combined with other SQL before being sent to the data source. This type of query can be used only with relational data sources. Native query text cannot be modified except by macro substitution, but can be combined with other query text into a single query text string to send to the data source. The syntax used must conform to that expected by the data source. Pass-through query text cannot be modified except by macro substitution, and cannot be combined with other query text. It must be sent to the data source as a stand-alone query. However, results can be combined with results of other queries. The syntax used must conform to that expected by the data source. A MDX query against a OLAP data source The text of the typed-in mdx. It is assumed to be appropriate for the type and data source. If it is not, the query may fail, or produce unexpected results. This contains the metadata returned for the typein query. The queryMetadata is optional and is not required in order to execute the query. UNION, INTERSECT, EXCEPT (MINUS) operations on one or more queries resulting in a projection list upon which other queries can be based. the list of items described in the query Determines whether the projection list is auto generated by the authoring tool. A calculated member is an item within a dimension that represents an occurrence of schema data defined as a calculation of two or more members. For example, “1999+2000” could be a calculated member of a “Time” dimension. For non-interactive output (pdf, xml, csv) this value is set to AllRows. For all other cases it is set to FirstRow. This value will be passed on to the underlying database, if it supports this type of optimization hint. The optimizer must adopt a plan that retrieves all rows of the result set in the least amount of time. This value is typically used in a batch environment. The retrieval of the result set is restricted to forward only iterators. The optimizer must adopt a plan that retrieves the first row as quicky as possible. This value is typically used in an interactive environment. The result set can be navigated back and forth as required. Identifies a dataItem as representing a named set. Defines the sets that are partitions of this set enable query reuse in RQP