Data Type Mismatch Error in Calculation View

[BenedictV]

Hi, 

I am trying to union a BW table and a ECC table in my calculation view. I am getting the following error,

Internal deployment of object failed;Repository: Encountered an error in repository runtime extension;Internal Error:Create Scenario: failed aCalcEngine.createScenario(): The following errors occured: Inconsistent calculation model (34011)nDetails (Errors):n- CalculationNode (Union_1): Datatype fixed12.3(15) of QUANTITY does not match to datatype fixed14.3(17) of attribute QUANT_B in node XXXXXX.n- CalculationNode (Union_1): Datatype fixed11.2(13) of SUBTOTAL does not match to datatype fixed15.2(17) of attribute SUBTOT_5S in node XXXXXXX

I tried creating a target field in the union(with predefined data type). I am not able to find any 'note' or forum discussions regarding this.

Can someone help me with this?

Regards,

Benedict

[BenedictV · Accepted solution]

I just created a 'projection' node and then created a new calculated column and changed the decimal sizes of "12.3(15) of QUANTITY" to 17,3 and "11.2(13) of SUBTOTAL" to 17,2 since those were the decimal sizes in the replicated BW tables and this solved it.

Will keep this discussion 'open' for sometime to see if there's a different solution to this and to confirm if my solution is the right approach.

Thanks,

Benedict

[justin_molenaur2 · Accepted solution]

I have had to do the same thing when I had different data types for two different sources within a union. As far as I know this is the only workaround.

Regards,

Justin

[Sumit_Gupta · Accepted solution]

Hello Benedict,

In my scenario I had a few tables that had the various ID's in multiple tables that were causing me issue.

To mention I was using the remote source MSSQL server to create virtual tables and the star join that was giving me the same issue.

To solve it the way I tried it is :

• Created a User Defined Scalar Function to convert BIGINT
• Created my dimension and Fact calculation views and used the scalar function to convert in semantics.
• I used the scalar function at both the places to make my columns same in fact and dimension that was giving me issues
• Used the Fact and Dimension Calculation views in Star Join and created it successfully.

Please let me know if you have any feedback.

Regards,

Sumit

[lbreddemann]

sumit.gupta : Sorry to tell you this, but besides the point that you resurrected a six-year old thread, you also came up with a way to solve the problem that isn't really good.

With the use of a UDF you do add quite a lot of overhead to every query execution where the converted columns are used. And that for something as simple and straight-forward as a type-cast.

Benedicts original solution - simply casting the columns to the desired data type in a projection - is correct and most effecient (if changing the underlying table is not an option).

I would highly recommend to review your solution and remove the scalar function if it does nothing more than changing the data type via casting.