Syntax for rules in dimension

[telula_w]

Hello,
I have this rule in a dimension

['ReportSign']=N: (IF(ELISANC('account','A110000',!account)=1,-1,1);

But it doesnt seem to take.Can anyone tell me if its a syntax issue? or if I cant use ELISANC in a dimension rule

[Kyro]

Code: Select all

['ReportSign']=N: IF(ELISANC('account','A110000',!account)=1,-1,1);

You had an additional open bracket at the start of the rule.

[telula_w]

That was a typo sorry.Below is the right one

['ReportSign']=N: IF(ELISANC('account','A110000',!account)=1,-1,1);

[Alan Kirk]

Hello,
I have this rule in a dimension

['ReportSign']=N: (IF(ELISANC('account','A110000',!account)=1,-1,1);

But it doesnt seem to take.Can anyone tell me if its a syntax issue? or if I cant use ELISANC in a dimension rule

I haven't come across the error "Doesn't seem to take" in the rules editor previously. It must be an undocumented one. Perhaps you could attach a screenshot so that we can record it for posterity?

Or failing that, provide the exact and specific error that you're getting. (Not to mention the exact and specific rule, copied directly from the rules editor to avoid "typos".) I believe that the request for assistance guidelines does mention something about this.

Similarly if you're getting unexpected results, specifics of what you're running, how, and what results you're getting will yield a more valuable response than "I'm running a T.I. but my code doesn't work properly".

But then, of course, it also contains this:

Let people know whether the answers that you received did (or didn't!) work for you. If someone searches for the same issue at some future time, that will help them to decide which suggestions might be the most beneficial for them to follow. Besides, posting a quick "Thank you, that solved my problem" is common courtesy in most societies, and is doubtless appreciated by the answerers.

which is observed more by some than others.

If the problem is not that the rule fails to compile, but that the formula never returns -1 (and we can't possibly know that from "doesn't seem to take"), check that A110000 really is the principal name of the consolidation that the elements fall under.

For the record, there's nothing wrong with the rule as such... provided that all of the arguments are valid.

[telula_w]

For the millions who will benefit, here is what i discovered, the rule will work if the attribute is a text. Somehow if the attribute is a numeric,it will not even grey out even though the syntax is accepted by the rules editor

TTTTTTTHHHHHHHAAAAAAANNNNNNKKKKK YYYYYYYYOOOOOOUUUUUU !!!!!

[Alan Kirk]

For the millions who will benefit, here is what i discovered, the rule will work if the attribute is a text. Somehow if the attribute is a numeric,it will not even grey out even though the syntax is accepted by the rules editor

TTTTTTTHHHHHHHAAAAAAANNNNNNKKKKK YYYYYYYYOOOOOOUUUUUU !!!!!

Oh, I'm sure that It won't be millions. It could well be some who take the time to do a search before asking questions because they recognise that other people are giving their time to answer those questions. (Probably the same kind of people who have enough courtesy and ability to think of others to acknowledge when someone has taken the time to give them an answer... without having it pointed out that they almost never do.) It will certainly only be the ones who realise when they reach the end of the thread that you were talking about assigning a rule to dimension attributes.

It'll probably be the same ones who, when they've been around long enough, will contribute something back to the community by trying to help other people rather than only turning up when they need help themselves.

But hey, different strokes for different folks.

[lotsaram]

For the millions who will benefit, here is what i discovered, the rule will work if the attribute is a text. Somehow if the attribute is a numeric,it will not even grey out even though the syntax is accepted by the rules editor

... may be a little late to party following Alan's post (right on and fully agree!) but mentioning that this was a rule in an }ElementAttributes cube would have been helpful from the outset. Although this was a "discovery" for you it is well known that numeric rules do not work in attribute cubes as attributes are essentially strings (even "numeric" ones). Had you mentioned the rule was for an attribute you would have gotten a quick answer. Also to Alan's point a search may have also turned up this information (although searching for previous threads relevant to your particular issue of the moment isn't always easy when you don't know exactly what you're searching for and how other's may have phrased it in their posts. I for one am happy to cut some slack on this as searching isn't always easy but it should always be attempted.)