TM1 Forum

Hi All and Happy Friday!

I am experiencing an issue with a rule that is trying to plug the difference between two cubes by rule. Unfortunately, the name of the first cube and one of its dimensions repeats, which causes the rule to error out.

Normally in a rule you can call out the dimension in front of elements with a duplicative name, but how do you handle a duplicative dimension name within a DB formula? Is this even possible? Unfortunately, remaking the cube is not currently an option.


[{'Midstream Contracts':'No_Contract','Midstream Customer':'No_Customer'}] = N: DB('Midstream Metrics',!Metrics Scenario,!MidstreamAssets,!MidstreamMetrics,!Year,!Period) - DB ( 'Midstream Metrics by Contract' , !MetricScenario , !MidstreamAssets , 'Midstream Contracts Subtotal' , 'Midstream Customers Subtotal' , !MidstreamContractMetrics , !Year , !Period ) ;

At a quick glance it looks like your braces are the issue, different dimensions within the braces, not removing ambiguity by specifying dimensions.

Thanks for looking at my issue, but removing the brackets did not help. The issue is that the cube "Midstream Metrics" and one of its dimensions have the same name.

What error message does it give you?
And what editor are you using: Architect, Workspace, Performance Modeler, Arc etc?

I don’t think any of my models have had cubes and dimensions with the same name but I feel like some of the sample IBM models did and I’m pretty sure it shouldn’t cause an issue - since the bang notation always refers to a dimension or hierarchy and not a cube.

Hi,

"The issue is that the cube "Midstream Metrics" and one of its dimensions have the same name."

If that is the issue, then have you created another cube with a different name and confirmed it resolves the problem?

Maren

I definately have models where cubes and dimensions share the same name. This doesn't cause any issue in rules. Your issue is something else.

lotsaram wrote: ↑Tue Oct 05, 2021 9:02 am I definately have models where cubes and dimensions share the same name. This doesn't cause any issue in rules. Your issue is something else.

Looks like something else - one 's' missing in second DB by the looks of it:
[{'Midstream Contracts':'No_Contract','Midstream Customer':'No_Customer'}] = N:
DB('Midstream Metrics',!Metrics Scenario,!MidstreamAssets,!MidstreamMetrics,!Year,!Period) -
DB('Midstream Metrics by Contract',!MetricScenario,!MidstreamAssets,'Midstream Contracts Subtotal','Midstream Customers Subtotal',!MidstreamContractMetrics , !Year , !Period );

Thanks for noticing the misspelling, but the error occurs earlier. Syntax error on or before: ' !Midstream Metrics , invalid string expression etc. See attached.

I am fairly certain remaking the cube with a different name would work, but the cube owner has business reasons not to want to do that at this particular time.

Do all of these dimensions exist in the cube that you are writing the rule for:
!Metrics Scenario
!MidstreamAssets
!MidstreamMetrics
!Year
!Period
!MetricScenario
!MidstreamContractMetrics


I expect that the issue you are seeing is more fundamental than the name of the cube/dimension being the same.

I am fairly certain remaking the cube with a different name would work, but the cube owner has business reasons not to want to do that at this particular time.

Can't you make absolutely certain by doing it as a test, call the cube ztest or something? When the test is done, delete the cube.

And if that is the issue then tell the cube owner the rule cant be added while the cube is named as it is!

Maren

Just to chip in that I fairly often call a cube and its measure dimension the same name and I've never known it cause an issue.

As others have said, it seems that the most likely answer is that there is a basic syntax / dimension reference error in your rule.

The invalid string expression error is normally arising from a !dimname reference to a dimension that is not in the cube in which the rule is written, as suggested by Declan

You have curly brackets on the left hand side of the rule that are not required. You are referencing different dimensions within them which may cause a problem

It's been a very long time since I looked at the parsing code but I seem to recollect that you can't do bang notation (!dimname) on a dimension name with a space in it. I'm probably wrong. Perhaps someone closer to the product could confirm or refute for me.

Duncan P wrote: ↑Thu Oct 07, 2021 10:39 pm It's been a very long time since I looked at the parsing code but I seem to recollect that you can't do bang notation (!dimname) on a dimension name with a space in it. I'm probably wrong. Perhaps someone closer to the product could confirm or refute for me.

Should be no problem.
This being said, I cannot imagine that a rule syntax takes over a week to be corrected, unless there’s holidays or other priorities of course.

Duncan P wrote: ↑Thu Oct 07, 2021 10:39 pm It's been a very long time since I looked at the parsing code but I seem to recollect that you can't do bang notation (!dimname) on a dimension name with a space in it. I'm probably wrong. Perhaps someone closer to the product could confirm or refute for me.

It is not a problem. Do it all the time.

Looking back through some old posts reminded me that the problem that I was misremembering was when you have it would think that the @ was part of the dimension name. Sorry for the confusion / memory loss.

Never saw a response on this regarding what the problem/solution was, but @flecky was correct on this it seems: the curly braces in the LHS addressing are telling the rule that elements from two dimensions are part of the same set.
should be: