Dimensional Coercion Rules in Cognos-Tpyes supported by cognos8

To help build expressions, Cognos 8 provides a coercive rule that automatically converts the dimensional types. With the enforcement rules, you can build a simple expression that makes them easier to understand. In addition to the implicit rules that Cognos 8 provides, you can specify these rules explicitly with different functions.

Cognos 8 supports the following types of coercion:
● forcing an object from one type to another dimension, a level set of
● forcing a three-dimensional object into a numeric value, date, time, or string value as a numerical measure to a numeric value
Coercion rules apply to the expressions and data elements. In expressions, operators, or functions may require the operands for a particular type of uniform. If the operand is not the one needed, one or more rules can be used coercion to force the operands to the appropriate type.
Coercion rules can be applied to the data elements to make the data element in the set of states or values.


Function Operands
Here's how coercion rules apply to operands of functions:
● If the operand requires no coercion is required.
● If the operand of the function must be a numeric value to one of coercion.
Typically there is a constraint for each type of coercion three-dimensional object.
● If the operand of the function must be three-dimensional object is forced to make operational the desired type of coercion is used.
● If there is no compulsion, an error code QE-DEF-0478 seems to indicate that conversion without the support of three-dimensional object from the source to the target type occurred.


Comparison of symmetric operators and other binary operators that accept operands of more than one type, such as equality (=) have to statisfy the condition "both operands are of the same type of uniform."
No coercion is possible between the value domains (numeric, date, time, and string), or between members and values. Consequently, if one operand is a value type, both must be in the same domain value. Otherwise, the request fails.
Members and sets of operands are valid only equality operators (=) is not equal to (<>),, and not where the right-hand side of the members, a set of elements, or strings. Only the following statements:
● [member/member set] = [member]
● [member/member set] <> [member]
● [member/member set] = ?p?
● [member/member set] <> ?p?
● [member/member set] in ([member], ...)
● [member/member set] not in ([member], ...)
● [member/member set] in ([member set])
● [member/member set] not in ([member set])
● [member/member set] in ?p?
● [member/member set] not in ?p?

What are the Exceptions?
To the left operand, a member of the set of supported detailed and concise expression of the filter, but not in terms that are used as a filter. Members are not supported in detail and summary filters, but they may be used in expressions that use the filter function.
Operands like in_range operator doesn't support the coercion rules and have normal coercion rules to them where as null operands are treated as values not the members.

Example for Dimensional Coercion Rules in Cognos
The following examples illustrate how coercion is applied to levels in expressions with operators.
[Sales].[Products].[].[Product Line] = [Sales].[Products].[].[Product Line]->
[Outdoor Equipment]
The left operand is coerced to the following member set:
members( [Sales].[Products].[].[Product Line])
The following expressions are invalid:
● [Sales].[Products].[].[Product Line] = NULL
● [Sales].[Products].[].[Product Line] + 1

1 comments:

Anonymous said...

excellent

Post a Comment