In SSAS 2008, there is the possibility to translate a key-only attribute just on a locale-specific basis: The name in the default attribute properties is left empty and the individual name columns are associated on a per-attribute/locale basis in the translation tab.
When the size of those columns changes, there is now the need to adapt it also in the name mapping. The place to to this is not quite obvious since the name property of the attribute is now empty: When selecting the attribute in the translation tab, go to the properties view and unfold the "CaptionColumn" property. Here you will find the important mapping information that you need to manipulate.
Posts mit dem Label Attribute werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Attribute werden angezeigt. Alle Posts anzeigen
Montag, 8. März 2010
Freitag, 29. Januar 2010
The difference between Order By Name and Order By Key in trivial attributes
This is a straigthforward follow-up to the last post.
Suppose you have a trivial attribute, i.e., its key is mapped to a single column of a relational data source. Its name and value has been ommitted, i.e., corresponds to a representation of the key.
Now Order By Name (which should be the default) will lead to a lexicographic order based on the representation while only Order By Key will use the natural ordering of the underlying data type.
I´m sure you or the various books of your choices did know this already. But I didn´t.
Suppose you have a trivial attribute, i.e., its key is mapped to a single column of a relational data source. Its name and value has been ommitted, i.e., corresponds to a representation of the key.
Now Order By Name (which should be the default) will lead to a lexicographic order based on the representation while only Order By Key will use the natural ordering of the underlying data type.
I´m sure you or the various books of your choices did know this already. But I didn´t.
Dienstag, 26. Januar 2010
The difference between Names and descriptive Attributes
Depending on the configuration of your SSAS landscape (DB/OS/Locale of the data source, OS/Server Locale and Column Collation of the SSAS machine/cluster), you can get very strange processing errors in your dimensions especially related to character-based attributes/names.
For example, the default collation settings in SSAS (ignore whitespaces, case-insensitivity) will usually unify more (European/German-rooted) strings than a "distinct" selection in the database of your choice. NULL entries which SSAS cannot stand at all in dimension processing are also a constant cause of problems in that respect ...
If you now wonder, why this leads to processing errors in certain attributes (duplicate key error) and not in others, please remind the setup of each attribute into a key and a name column (the latter pointing to the former in the standard-case).
One of the fundamental differences between the two is that a "select distinct" of the key columns MUST NOT have two rows which will be unified by SSAS collation processing while this is not necessarily true for name columns in which case an arbitrary value is taken as the representative.
For example, the default collation settings in SSAS (ignore whitespaces, case-insensitivity) will usually unify more (European/German-rooted) strings than a "distinct" selection in the database of your choice. NULL entries which SSAS cannot stand at all in dimension processing are also a constant cause of problems in that respect ...
If you now wonder, why this leads to processing errors in certain attributes (duplicate key error) and not in others, please remind the setup of each attribute into a key and a name column (the latter pointing to the former in the standard-case).
One of the fundamental differences between the two is that a "select distinct" of the key columns MUST NOT have two rows which will be unified by SSAS collation processing while this is not necessarily true for name columns in which case an arbitrary value is taken as the representative.
Abonnieren
Posts (Atom)