Attributes not visible in Cube when adding with AMO and Hierarchyenabled = false

I need help with a big problem.

I'm using AMO to add new Attributes to a Dimension and I have to use AttributeHierarchyEnabled property = false as Default.

But then I'm never able again to see the Attribute in the Cube though I change with Visiual Studio the property to true.

If use AttributeHierarchyEnabled = true all works fine.

Dimension dim = mDataBase.Dimensions.GetByName(Attr.DimensionName);

DimensionAttribute Attribute = dim.Attributes.FindByName(Attr.AttributeName);

Attribute = new DimensionAttribute();

Attribute.Name = Attr.AttributeName;

Attribute.ID = Attr.AttributeName;

...

Attribute.AttributeHierarchyEnabled = true;

dim.Attributes.Add(Attribute);

Thanks for any help.

You need set the AttributeHierarchyEnabled to true for both DimensionAttribute and CubeAttribute in AMO.

In visual studio, you need change the property both in dimension attribute property dialog and cube attribute dialog.

Attribute Limit of 5000 When Mining a Cube

I'm trying to build a association model in the Standard Edition based on an existing cube. I keep getting the error:

Error (Data mining): The 'Product Recommendations' mining model has 60385 attributes. This number of attributes exceeds the attribute limit of 5000 allowed by the current version of the algorithm associated with the mining model.

I created Cube Slice filters and those limit the Customer and Product dimensions (Product is Nested) to well under 5000. The error message also does not change. The number of attributes is equal to the number of rows in the Product dimension, but I expected the cube slice to reduce the number. I tested all the SQL used while it processes and with the MDXFilters the number of rows returned is well under 5000.

So, in short, the final questions is, is it possible to create a mining model in standard edition based on an existing cube where the nested dimension in the model has more than 5000 rows? Is there some other way to filter the query?

I guess my only choice on this if there isn't a way is to extract the data into relational table with only the rows I want to analyze....that's a huge pain and doesn't really make sense when the filters should limit the model size.

What is annoying on this is I can't find one reference anywhere on the microsoft site that this limit even exists within the product...

Thanks for any assistance on this!

This sounds like a bug (and knowing the code, I can see where it comes from).

Standard edition is limited to 5000 attributes for Standard Edition. What you are doing is perfectly legal, assuming there are actually less than 5000 attributes. You may need to contact support so we can get this fixed, or start by writing up a bug report at connect.microsoft.com. If you cannot get this resolved through support and this is blocking you, please let us know and we will see if we can make something happen.

Thanks

-Jamie

|||

Thanks...I'll get a support case open and see what happens.

- L

|||

Jamie,

I opened a support case with Microsoft and have been working with them for a few days. They did agree that this is a defect in the product. The current response is that, "they may consider a design change to account for filtered cube slices". This is a pretty big deal for our development. I'd also question the limit in general since its not even documented, does the limit really drive more sales to the Enterprise Version of the product? I think if there is a limit, it should really be much larger since in practice, 5000 rows in a nested table is so small. It is very common for small companies to have product catalogs of 60k products.

THANKS!

|||

I have been working with the support person you are in contact with. The issue isn't if the problem with be fixed, it is simply how the problem will be fixed. I believe we will have a resolution today - in any case, it will resolve the issue you are seeing.

Regarding the 5000 attribute limit, that's a completely seperate debate that I don't want to get deeply into in the forums. I would only state that the differentiation between the various editions isn't limited to data volumes, functional differences arise as well (e.g. data mining transforms in Integration Services, etc.). Your cost structure in general may not support a wholesale changeover to Enterprise edition due to data volumes, but the ROI of some of the features that are made available in the larger edition may warrant an upgrade on a single machine. There are different licensing options for this as well, i.e. server CAL vs Processor licences, which for a small-medium size business, a 50-CAL Enterprise license may do the trick and still be in the affordable price range.

If you want to contact me directly, it's Jamie <dot> MacLennan <at> microsoft <dot> com

Thanks

Attribute Limit of 5000 When Mining a Cube

I'm trying to build a association model in the Standard Edition based on an existing cube. I keep getting the error:

Error (Data mining): The 'Product Recommendations' mining model has 60385 attributes. This number of attributes exceeds the attribute limit of 5000 allowed by the current version of the algorithm associated with the mining model.

I created Cube Slice filters and those limit the Customer and Product dimensions (Product is Nested) to well under 5000. The error message also does not change. The number of attributes is equal to the number of rows in the Product dimension, but I expected the cube slice to reduce the number. I tested all the SQL used while it processes and with the MDXFilters the number of rows returned is well under 5000.

So, in short, the final questions is, is it possible to create a mining model in standard edition based on an existing cube where the nested dimension in the model has more than 5000 rows? Is there some other way to filter the query?

I guess my only choice on this if there isn't a way is to extract the data into relational table with only the rows I want to analyze....that's a huge pain and doesn't really make sense when the filters should limit the model size.

What is annoying on this is I can't find one reference anywhere on the microsoft site that this limit even exists within the product...

Thanks for any assistance on this!

This sounds like a bug (and knowing the code, I can see where it comes from).

Standard edition is limited to 5000 attributes for Standard Edition. What you are doing is perfectly legal, assuming there are actually less than 5000 attributes. You may need to contact support so we can get this fixed, or start by writing up a bug report at connect.microsoft.com. If you cannot get this resolved through support and this is blocking you, please let us know and we will see if we can make something happen.

Thanks

-Jamie

|||

Thanks...I'll get a support case open and see what happens.

- L

|||

Jamie,

I opened a support case with Microsoft and have been working with them for a few days. They did agree that this is a defect in the product. The current response is that, "they may consider a design change to account for filtered cube slices". This is a pretty big deal for our development. I'd also question the limit in general since its not even documented, does the limit really drive more sales to the Enterprise Version of the product? I think if there is a limit, it should really be much larger since in practice, 5000 rows in a nested table is so small. It is very common for small companies to have product catalogs of 60k products.

THANKS!

|||

I have been working with the support person you are in contact with. The issue isn't if the problem with be fixed, it is simply how the problem will be fixed. I believe we will have a resolution today - in any case, it will resolve the issue you are seeing.

Regarding the 5000 attribute limit, that's a completely seperate debate that I don't want to get deeply into in the forums. I would only state that the differentiation between the various editions isn't limited to data volumes, functional differences arise as well (e.g. data mining transforms in Integration Services, etc.). Your cost structure in general may not support a wholesale changeover to Enterprise edition due to data volumes, but the ROI of some of the features that are made available in the larger edition may warrant an upgrade on a single machine. There are different licensing options for this as well, i.e. server CAL vs Processor licences, which for a small-medium size business, a 50-CAL Enterprise license may do the trick and still be in the affordable price range.

If you want to contact me directly, it's Jamie <dot> MacLennan <at> microsoft <dot> com

Thanks

attribute key was not found error

everytime i try to process my cube i get this error:

Errors in the OLAP storage engine: The attribute key cannot be found:

Table: dbo_MCSFinFactData, Column: InvoiceDateDimensionID, Value: 15.

Errors in the OLAP storage engine: The record was skipped because the attribute key was not found.

Attribute: InvoiceDateDimensionID 8 of Dimension: InvoiceDate Fiscal Year 2 from Database:

SRDBAnalysis, Cube: MCSFinancial, Measure Group: MCSFinancial, Partition: MCSFinancial, Record: 10.

I have checked the dimension table and the record with an invoicedatedimensionid value of 15 exists. there are also many records in the fact table that use an invoicedatedimensionid of 15. if the record exists in both tables, why does it say the attribute key was not found?

i have resolved this, only i dont understand why my actions resolved the issue and was hoping someone could explain.

in the error( in the above post) you see the attribute was "invoiceDate fiscal year 2". i just processed the attribute manually, and had to do the same with a handfull of other attributes, and now the cube works. why is this? also , is there a quicker way, as id rather not have to process 20 - 30 attributes manually each time there is a problem!

|||

Here is another thread on the same matter

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1198671&SiteID=1

The ultimate resolution should be fixing referential integrity problems in relational database and not processing dimensions in different order.

BTW, you cannot process a single attribute by itself

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

|||there are no referential integrity issues within my database. i have made 100% sure of this. this database has been in use for 6 years with analysis services 2000, and there were never processing errors, and the processing was set to tolerate no errors. so it cannot be a database issue. im wondering if i just have to recreate the cubes completely in analysis server 2005? this isnt upgrade any more, its just redevelopment of old projects.|||

Analysis Services 2005 is little bit more strict when comapred to AS2000 in the way it is detecting inconsistencies in relational database. If you run SQL Profiler you'd mention that it is also uses different strategy when querying relational database during processing.

Every attribute is processed separately and in case of AS2000 you'd see a one query per dimension, in AS2005 you see multiple SQL queries sent- one per dimension attribute.

See this paper describing new processing architechture: http://msdn2.microsoft.com/en-us/library/ms345142.aspx

As for detecting inconsistensies in relational database, it could be tricky. For instance, the reason Analysis Server wouldnt find a key for attribute member is; you allowed for processing ignore records with repeated key. Set KeyDuplicate to ReportAndStop. In fact set ReportAndStop for every setting in ErrorConfiguration for your processing command.

Here is whitepaper talks about setting error configuration http://msdn2.microsoft.com/en-us/library/ms345138.aspx

And it is also important to review new dimension stucture and see what becomes a source for attribute key column/s and what it is name.

Migration process might have some quirks in some complex cases mapping AS2000 database to AS2005. As for Analysis Server detecting missing keys - every time I run into missing key case it is always comes down to some modeling or data issues.

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

Attribute Key Cannot Be Found: Single Underlying Table!

I've spent quite a bit of time searching this topic and have not come up with an answer that would help my situation.

I'm building a cube from a single table. That table is used to build both the attributes and measures. I sometimes get the "attribute key cannot be found" error even though queries prove that the data indeed there. Often all that needs to happen to fix the problem is to simply reprocess the cube without making any changes.

Any ideas as to how I could fix this problem? It causes a problem as the cube is scheduled and that is failing. I can't be rebuilding the cube manually each day.

Hello! Even if you have fact table dimensions this problem can be related to that you must always process the dimensions first and the rest of the cube later. If you use MOLAP for storage the dimensions will be built as separate objects even if you use a single table as source.

If you process the cube and have activated "process related objects" in the advanced settings dialogue you can process the cube and the dimensions will be processed first.

HTH

Thomas Ivarsson

|||Perfect! That you so much for your help, Thomas. That makes good sense. I've set the Integration Service project to Process Related Objects.

Thanks Again,

Robin Sarac

edit: Spelling mistakes...

attribute key cannot be found - regular hierarchy

I am a newbie in Analysis Services. I have just designed a cube, drawing data from a bigger database. In the cube measures are about responses to questionnairies. There are 3 dimensions: question, time of response and user (who responded).

The user hierarchy is a user-enterprise-activity hierarchy.

When the cube is processed I receive the following error when it reaches to process the enterprise part:

Warning 1 Errors in the OLAP storage engine: The attribute key cannot be found: Table: dbo_Activity, Column: Id, Value: {F1B5099A-F1D4-4156-945E-0D733EB71C8C}. 0 0
(then it believes to be unknown, it finds too many errors and stops).

This value is a correct value for an activity Id. But I suppose this means that the link between enterprise and activity doesn't work (it's perfectly ok in the relational database). But I cannot find why.

SELECT
DISTINCT
[dbo_Activity].[Id] AS [dbo_ActivityId0_0],[dbo_Activity].[EnglishDescription] AS [dbo_ActivityEnglishDescription0_1],[dbo_Activity].[FrenchDescription] AS [dbo_ActivityFrenchDescription0_2]
FROM
(

SELECT Activity.Id, LocalizedActivity.Description AS EnglishDescription, LocalizedActivity_1.Description AS FrenchDescription,
LocalizedActivity_2.Description AS GreekDescription, LocalizedActivity_2.NationalCode AS GreekCode, LocalizedActivity.NationalCode AS EnglishCode,
LocalizedActivity_1.NationalCode AS FrenchCode
FROM Activity INNER JOIN
LocalizedActivity ON Activity.Id = LocalizedActivity.ActivityId INNER JOIN
LocalizedActivity AS LocalizedActivity_1 ON Activity.Id = LocalizedActivity_1.ActivityId INNER JOIN
LocalizedActivity AS LocalizedActivity_2 ON Activity.Id = LocalizedActivity_2.ActivityId
WHERE (LocalizedActivity.Language = 'en-GB') AND (LocalizedActivity_1.Language = 'fr-FR') AND (LocalizedActivity_2.Language = 'gr-GR')
)
AS [dbo_Activity]
Processing Dimension Attribute 'Enterprise' failed. 1 rows have been read.
Start time: 24/5/2006 5:19:28 μμ; End time: 24/5/2006 5:19:28 μμ; Duration: 0:00:00
SQL queries 1
SELECT
DISTINCT
[dbo_Enterprise].[Id] AS [dbo_EnterpriseId0_0],[dbo_Enterprise].[Name] AS [dbo_EnterpriseName0_1],[dbo_Enterprise].[NationalCode] AS [dbo_EnterpriseNationalCode0_2],[dbo_Enterprise].[PrimaryActivity] AS [dbo_EnterprisePrimaryActivity0_3]
FROM
(

SELECT Id, Name, PrimaryActivity, NationalCode
FROM Enterprise
)
AS [dbo_Enterprise]

Can you post some more information about you situation.

Is error you receive is happening during processing of dimension or partition? If you are processing entire cube, please try to process your dimensions firts and then process partition, by partition.

What is the stucture of your user dimension?

I also see some non-english descriptions in the query, where do they come from?

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

|||Thank you very much for the interest in helping.
Sorry for the short delay, my internet connection was just lame this morning.

The problem is happening during cube processing, but also during user dimension processing.

The user dimension comes from this named query (yes it's a bit familiar for those accustomed to asp.net ;)):
SELECT aspnet_Users.UserId, aspnet_Users.UserName, aspnet_Users.Enterprise, aspnet_Membership.Email
FROM aspnet_Users INNER JOIN
aspnet_Membership ON aspnet_Users.UserId = aspnet_Membership.UserId

Afterwards in the User dimension hierarcy,
User (...) has Enterprise and User Name as attributes,
Enterprise (..) has Activity, Name_ and National Code as attributes and
Activity (.) has English Description and French Description as attributes

Detailed code in the end of the post

The descriptions, as it is shown in the code in the first post come from LocalizedActivity table. Activity is thus a named query, drawing data from the activity table and the localized activity one (multiple lines for the latter, two for english language, two for french and two for greek - yes I know, it's a strange combination of languages ;)).

[Code for the dimension in case it helps]
<Source xsi:type="DataSourceViewBinding" dwd:design-time-name="fae66f4d-967b-400e-9dd5-fe6ba89a6771">
<DataSourceViewID>Local Sql Server</DataSourceViewID>
</Source>
<UnknownMember>Visible</UnknownMember>
<CurrentStorageMode>Molap</CurrentStorageMode>
<Attributes>
<Attribute dwd:design-time-name="623f18b9-82f5-4641-9b53-e159ef88c0a3">
<ID>Aspnet Users</ID>
<Name>Aspnet Users</Name>
<Usage>Key</Usage>
<EstimatedCount>2</EstimatedCount>
<KeyColumns>
<KeyColumn dwd:design-time-name="7c5aecb6-c79f-489f-b16d-517a00536a99">
<NullProcessing>UnknownMember</NullProcessing>
<DataType>WChar</DataType>
<Source xsi:type="ColumnBinding" dwd:design-time-name="5c6894e9-7c7e-4d9e-a5e0-0db5e73af31a">
<TableID>dbo_aspnet_Users</TableID>
<ColumnID>UserId</ColumnID>
</Source>
</KeyColumn>
</KeyColumns>
<AttributeRelationships>
<AttributeRelationship dwd:design-time-name="9a225117-5e19-4e93-98ca-1f9c8aecbb34">
<AttributeID>User Name</AttributeID>
<Name>User Name</Name>
</AttributeRelationship>
<AttributeRelationship dwd:design-time-name="4bd453e1-04c5-44d4-925a-07b781710eb9">
<AttributeID>Enterprise</AttributeID>
<Name>Enterprise</Name>
</AttributeRelationship>
</AttributeRelationships>
<OrderBy>Key</OrderBy>
<InstanceSelection>DropDown</InstanceSelection>
</Attribute>
<Attribute dwd:design-time-name="4d504c73-5be5-4643-ad53-5945dbe0093e">
<ID>User Name</ID>
<Name>User Name</Name>
<Type>PersonFullName</Type>
<EstimatedCount>2</EstimatedCount>
<KeyColumns>
<KeyColumn dwd:design-time-name="1e48b643-917b-4cab-ac8e-c2b5b5836ef3">
<DataType>WChar</DataType>
<DataSize>256</DataSize>
<Source xsi:type="ColumnBinding" dwd:design-time-name="6047a2f6-953b-428a-86bf-59a4a716c9bb">
<TableID>dbo_aspnet_Users</TableID>
<ColumnID>UserName</ColumnID>
</Source>
</KeyColumn>
</KeyColumns>
<NameColumn dwd:design-time-name="c8a05998-f1cb-4a4b-bfbc-dc6412078020">
<DataType>WChar</DataType>
<DataSize>256</DataSize>
<Source xsi:type="ColumnBinding" dwd:design-time-name="72d2f7aa-9128-4f32-8c99-3393eade848f">
<TableID>dbo_aspnet_Users</TableID>
<ColumnID>UserName</ColumnID>
</Source>
</NameColumn>
<OrderBy>Key</OrderBy>
<InstanceSelection>DropDown</InstanceSelection>
</Attribute>
<Attribute dwd:design-time-name="5eda6b5e-78ef-4c22-8000-3a93dd23d6a4">
<ID>Enterprise</ID>
<Name>Enterprise</Name>
<KeyColumns>
<KeyColumn dwd:design-time-name="9c5e9ce9-d304-4fb3-b1c4-cbffee628798">
<NullProcessing>UnknownMember</NullProcessing>
<DataType>WChar</DataType>
<Source xsi:type="ColumnBinding" dwd:design-time-name="b1fea07e-c3cd-4811-aebc-21d90d834bec">
<TableID>dbo_Enterprise</TableID>
<ColumnID>Id</ColumnID>
</Source>
</KeyColumn>
</KeyColumns>
<NameColumn dwd:design-time-name="b50a3458-488b-45a2-8e33-5237b26fe3b6">
<DataType>WChar</DataType>
<DataSize>50</DataSize>
<Source xsi:type="ColumnBinding" dwd:design-time-name="13b0aaa9-c817-46b5-9609-36039dc8e487">
<TableID>dbo_Enterprise</TableID>
<ColumnID>Name</ColumnID>
</Source>
</NameColumn>
<AttributeRelationships>
<AttributeRelationship dwd:design-time-name="4a5648da-1625-4b0d-9911-41c45ab64325">
<AttributeID>National Code</AttributeID>
<Name>National Code</Name>
</AttributeRelationship>
<AttributeRelationship dwd:design-time-name="1f5d1cdb-3872-4d6b-97fc-e81cabd89429">
<AttributeID>Name</AttributeID>
<Name>Name_</Name>
</AttributeRelationship>
<AttributeRelationship dwd:design-time-name="c7be6cbf-f255-420c-8d70-c4b24d80706f">
<AttributeID>Activity</AttributeID>
<Name>Activity</Name>
<Visible>false</Visible>
</AttributeRelationship>
</AttributeRelationships>
<OrderBy>Key</OrderBy>
<InstanceSelection>DropDown</InstanceSelection>
</Attribute>
<Attribute dwd:design-time-name="5fa36ff1-0d08-4336-9bd7-90c15a6baf53">
<ID>National Code</ID>
<Name>National Code</Name>
<KeyColumns>
<KeyColumn dwd:design-time-name="8ec125a2-426e-41d1-bdf2-5c07b540b41b">
<DataType>WChar</DataType>
<DataSize>16</DataSize>
<Source xsi:type="ColumnBinding" dwd:design-time-name="eaeb27bc-d602-4e02-992c-8d619633b365">
<TableID>dbo_Enterprise</TableID>
<ColumnID>NationalCode</ColumnID>
</Source>
</KeyColumn>
</KeyColumns>
<OrderBy>Key</OrderBy>
</Attribute>
<Attribute dwd:design-time-name="5248c844-b5b4-4946-be3b-cd035c7d36d7">
<ID>Name</ID>
<Name>Name</Name>
<Type>Caption</Type>
<KeyColumns>
<KeyColumn dwd:design-time-name="30bbddd9-ebb1-4570-ac88-1825911cca8d">
<DataType>WChar</DataType>
<DataSize>50</DataSize>
<Source xsi:type="ColumnBinding" dwd:design-time-name="7b76b669-47bf-403e-b5e9-c95480031621">
<TableID>dbo_Enterprise</TableID>
<ColumnID>Name</ColumnID>
</Source>
</KeyColumn>
</KeyColumns>
<OrderBy>Key</OrderBy>
</Attribute>
<Attribute dwd:design-time-name="94b00c3c-bdb6-434e-93be-59cd8b702c86">
<ID>Activity</ID>
<Name>Activity</Name>
<KeyColumns>
<KeyColumn dwd:design-time-name="7e570409-f592-460b-83bb-7d36bd5c83ef">
<NullProcessing>UnknownMember</NullProcessing>
<DataType>WChar</DataType>
<Source xsi:type="ColumnBinding" dwd:design-time-name="633bf76c-9410-4513-9933-b3439975ce44">
<TableID>dbo_Activity</TableID>
<ColumnID>Id</ColumnID>
</Source>
</KeyColumn>
</KeyColumns>
<AttributeRelationships>
<AttributeRelationship dwd:design-time-name="376c55ce-bff9-48a1-bc19-0985819f9af8">
<AttributeID>Description</AttributeID>
<Name>EnglishDescription</Name>
</AttributeRelationship>
<AttributeRelationship dwd:design-time-name="612f91ad-e799-4aaa-bf7f-08a13a7a69ec">
<AttributeID>EnglishDescription 1</AttributeID>
<Name>FrenchDescription</Name>
</AttributeRelationship>
</AttributeRelationships>
<OrderBy>Key</OrderBy>
</Attribute>
<Attribute dwd:design-time-name="e6bcad35-b68c-477a-a03a-3f6b5de37d69">
<ID>Description</ID>
<Name>EnglishDescription</Name>
<Type>Caption</Type>
<KeyColumns>
<KeyColumn dwd:design-time-name="6a48f875-38dd-449f-8c4b-a037be5851b4">
<DataType>WChar</DataType>
<DataSize>128</DataSize>
<Source xsi:type="ColumnBinding" dwd:design-time-name="aa6ce269-8d62-408c-b7a9-538eee58708c">
<TableID>dbo_Activity</TableID>
<ColumnID>EnglishDescription</ColumnID>
</Source>
</KeyColumn>
</KeyColumns>
<OrderBy>Key</OrderBy>
</Attribute>
<Attribute dwd:design-time-name="51245cda-daf1-43d5-9c16-83f03c58c84d">
<ID>EnglishDescription 1</ID>
<Name>FrenchDescription</Name>
<Type>Caption</Type>
<KeyColumns>
<KeyColumn dwd:design-time-name="16b37f49-cbd4-4e2b-ad2f-87053b15083b">
<DataType>WChar</DataType>
<DataSize>128</DataSize>
<Source xsi:type="ColumnBinding" dwd:design-time-name="4fcc5408-b96d-4e24-b3d6-43bb33ca345b">
<TableID>dbo_Activity</TableID>
<ColumnID>FrenchDescription</ColumnID>
</Source>
</KeyColumn>
</KeyColumns>
<OrderBy>Key</OrderBy>
</Attribute>
</Attributes>
<Hierarchies>
<Hierarchy dwd:design-time-name="80e30aa7-1d98-49a3-ae89-14022ba5ff24">
<ID>Activity - Enterprise</ID>
<Name>Activity - Enterprise</Name>
<Levels>
<Level dwd:design-time-name="aaba10df-78c3-4509-b520-52b6e6fe656f">
<ID>Activity</ID>
<Name>Activity</Name>
<SourceAttributeID>Activity</SourceAttributeID>
</Level>
<Level dwd:design-time-name="05e46e50-bb6e-4f14-b4c8-2609dc5a9fb6">
<ID>Enterprise</ID>
<Name>Enterprise</Name>
<SourceAttributeID>Enterprise</SourceAttributeID>
</Level>
<Level dwd:design-time-name="348e276e-dc64-4665-b8ac-64f5739b40c4">
<ID>Aspnet Users</ID>
<Name>User</Name>
<SourceAttributeID>Aspnet Users</SourceAttributeID>
</Level>
</Levels>
</Hierarchy>
</Hierarchies>|||

It is bit strange...

Your error indicates:

Table: dbo_Activity, Column: Id, Value: {F1B5099A-F1D4-4156-945E-0D733EB71C8C}

But little below from there I see error message: Processing Dimension Attribute 'Enterprise' failed. 'Enterprise' attribute is based on the dbo_Enterprise table.

Processing of which attribute is failing?

Another observation, are you running Enterprise version of Analysis Services? In this case you should be able to take advantage of Translations feature and get rid of extra description in French and Greek.

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

|||The process of Enteprise attribute is failing. I also don't get whiy I have a warning regarding dbo_Activity but a problem in enterprise.
The full list of errors is the following (I now check it again and I put to bold something I find interesting):
Errors in the OLAP storage engine: The attribute key cannot be found: Table: dbo_Activity, Column: Id, Value: {F1B5099A-F1D4-4156-945E-0D733EB71C8C}. Errors in the OLAP storage engine: The attribute key was converted to an unknown member because the attribute key was not found. Attribute Enterprise of Dimension: User from Database: QueStorm, Record: 2.
Errors in the OLAP storage engine: The attribute key cannot be found: Table: dbo_Activity, Column: Id, Value: {F1B5099A-F1D4-4156-945E-0D733EB71C8C}. Errors in the OLAP storage engine: The attribute key was converted to an unknown member because the attribute key was not found. Attribute Enterprise of Dimension: User from Database: QueStorm, Record: 2. Errors in the OLAP storage engine: The process operation ended because the number of errors encountered during processing reached the defined limit of allowable errors for the operation. Errors in the OLAP storage engine: An error occurred while the 'Enterprise' attribute of the 'User' dimension from the 'QueStorm' database was being processed.
Errors and Warnings from Response
Errors in the OLAP storage engine: The process operation ended because the number of errors encountered during processing reached the defined limit of allowable errors for the operation.
Errors in the OLAP storage engine: An error occurred while the 'Enterprise' attribute of the 'User' dimension from the 'QueStorm' database was being processed.
Errors in the OLAP storage engine: The process operation ended because the number of errors encountered during processing reached the defined limit of allowable errors for the operation.
Errors in the OLAP storage engine: The attribute key cannot be found: Table: dbo_Activity, Column: Id, Value: {F1B5099A-F1D4-4156-945E-0D733EB71C8C}.
Errors in the OLAP storage engine: The attribute key was converted to an unknown member because the attribute key was not found. Attribute Enterprise of Dimension: User from Database: QueStorm, Record: 2.

I run Standard version. In any case, I need the French descriptions for the relational part of the application (so the table is already there, filled).|||

The problem I beleive is following:

When processing your Activity attribute, Analysis Server will send a SQL query to read all ActivityId's and will save these ActivityId's as keys for Activity attribute

While processing Enterprise attribute, it will send SQL query for EnterpriseId and also for matching ActvityId to know what is going to be the parent Activity for specific Enterprise.

Try copy SQL query for Activity attribute from processing dialog and append "Where" clause to it with ActivityId you getting from the Enterprise attribute error and send it directly. I suspect you will get an empty result.

The problem could be with the way you defined your Descritpion columns in SQL server. You need to make sure you set the collation correctly on Descriotion columns.

But this just a theory. Try doing the experiment above and see if get any results from the SQL query.

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

|||Try copy SQL query for Activity attribute from processing dialog and append "Where" clause to it with ActivityId you getting from the Enterprise attribute error and send it directly. I suspect you will get an empty result.

Send it directly to where? Try it in Server Management Studio, that is? Or modify the named query for the Enterprise?

Thank you very much, I suspect some recent changes I made to the enterprise description (I tried to use the enterprise name as the description field of the enterprise instead of the key and I suspect it didn't work)
|||When running the query with the above id in the data view query editor, the results are ok (not empty).

Changing the name attribute didn't solve the problem

I send here an image in case it helps:
http://recursive-cacophony.net/tec-goblin/Irrelevant/UserDim.PNG
BTW, in ff this control works weirdly (I cannot use html code)|||

May be the last thing before I give up:)

Try creating new tables for your French and Greek descriptions: LocalizedActivity_1_F and LocalizedActivity_2_G

When creating these tables set collation for Description column to Latin1_General_BIN (I assume you are using SQL Server as your relational database ).

Populate these tables with data from LocalizedActivity_1 and LocalizedActivity_2, change your named query to point to the new tables and try processing dimension again.

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

|||Yeich, this would ruin my architecture - you mean I have to create tables in the data source or in the relational database? I am not considering changing the relational database at this moment. (Btw, greek have their special collation rules - the alphabet is different and they are accent sensitive - and I use this as default collation in the database, without having seen any problem 'till now).
Finally, I am not even using the greek description in the cube.

In SQL Server Management Studio I can see data in all languages perfectly, and all fields are nvarchar, in the Cube they are wchar, I don't see many ways this could be a problem... :S|||Well, I finally found what was the problem. It had not to do with the cube, nor with the collation. It is actually in the select statement I have in the first post:

Using INNER JOIN (as the query designer always does) is a bad idea when sometimes the entries do not exist : for example there are no greek nor english descriptions for the activities right now in the database (it is for future use). So, if you use inner joins instead of nested select statements, you lose all the row, so instead of something like:

[anactivityId] [anactivityFrenchDescription] null null

you have no row at all.