SSAS: varchar/nvarchar column size incorrectly mapped between data source views and cube dimensions - by Matija Lah

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


12
0
Sign in
to vote
ID 298085 Comments
Status Closed Workarounds
Type Bug Repros 3
Opened 9/14/2007 4:20:48 AM
Access Restriction Public

Description

When large varchar/nvarchar data type columns are used in the data source views their size is not properly set in the cube dimension definitions causing the following exception when the dimension is processed:

"The size specified for a binding was too small, resulting in one or more column values being truncated."

For instance:
- for nvarchar(4000) the DataSize property of the corresponding dimension is set at 1024;
- for nvarchar(max) the DataSize property of the corresponding dimension is not set at all.


Further more, specifying the maximum size for varchar/nvarchar(max) data type in the dimension to 2147483647 causes the following exception when the dimension is processed:

"Memory error: Allocation failure : Not enough storage is available to process this command."

In fact any size larger than 163315555 causes the memory error.


The data type itself is mapped appropriately (i.e. to WChar as expected).

Warning: this problem occurs even when the cube and its dimensions are created for the first time, not only after the data source view has been changed and the changes have not been propagated manually to the dimension definitions.
Sign in to post a comment.
Posted by Ashish Khade on 10/26/2015 at 8:26 AM
Due to 1 attribute of type varchar max, entire cube processing was failing. I set dimension storage to ROLAP having this attribute, so at least cube was live soon. I couldn't find any workaround yet except limiting data at DB side.

Please fix this asap. We are using SQL 2012 version.

Posted by WDM14 on 10/20/2011 at 9:35 AM
I know this has been marked as "Won't fix" but I stuggle to understand why? I litterally can't load certain custom rollups formulas because this is limiting the length of the string. Quit adding stupid features to this and just make your product work. A string is a string and should not be called a string if it isn't.
You are so out of touch with your business users it is ridiculous. Fix your bugs before you do anything else.
Posted by Matija Lah on 7/14/2008 at 6:03 AM
Thank you for the reply.

I guess properly implementing all SQL data types throughout the SQL Server platform would probably also get rid of this particular flaw.

But that's a matter for a separate bug report/suggestion.


Kind regards,
Matija Lah
Posted by Microsoft on 10/29/2007 at 12:36 PM
Thanks for reporting this issue. This is not something we will be able to address for the current release but will certainly consider for a future release.

Regards,
Rob Zare