TM1 Forum

We just installed 10.2.2 fixpack 2 in our DEV environment. This rule for an attribute in the }ElementAttribute cube:
worked fine but stopped working immediately after the fixpack was installed. The cube cells do not even show a rule as applying to them.

It is still working fine in QA and Production, so further upgrading to Fixpack 2 is temporarily halted. Has anyone run into this problem? We have tried the following:

• using = N: notation
  converting the value to be stored to a string
  ['Director_Subset_Flag'] = 99;
  ['Director_Subset_Flag'] = N:99;

all to no avail.

Any ideas or solutions to this problem? Or an alternative? We are wanting to create dynamic subsets from dynamically calculated attributes on the dimension elements. As stated, we have this working in QA and Prod, just lost it in DEV when we upgraded a few days ago.

Additional note: rules on string elements appear to be functioning normally.

Thanks in advance.

Ty

PavoGa wrote:

• using = N: notation
  converting the value to be stored to a string
  ['Director_Subset_Flag'] = 99;
  ['Director_Subset_Flag'] = N:99;

Try:

Declanr,

That works and is about the only thing we did not try. It was confusing in that it worked, but stopped with the fixpack.

Thenk ye.

Ty

Hi Pavgpa

Just to add to this, I am guessing that the attribute is a Numeric Attribute. These are a little odd. If you look at the DTYPE of a Numeric Attribute it will show as AN rather than N.

I believe that Numeric Attributes are physically held as Strings. For example, you can enter a value into a Numeric Attribute at a consolidated level, which you cannot do with a normal Numeric element.

In some cases you have to treat them are numbers, eg in TI ATTRN returns a numeric. However, in other cases you need to treat them as strings. It can be difficult other than trial and error to work out exactly what those other cases are.

Regards

Paul Simon

Thanks, Paul.

Well a new and even more interesting twist. The solution Declan provided works fine...for 10.2.2 fixpack 2. HOWEVER, it does not work for fixpack 1. We tested by promoting the rule up to our QA environment which was not upgraded on purpose to expressly test this and the rule no longer works.

Which I hate because we do not really want code that works differently depending on the version of TM1. Sooooooo...barring figuring out someway around this that works for both fixpacks, we will have to manage code by fixpack. yuck...

Ty

PavoGa wrote:Which I hate because we do not really want code that works differently depending on the version of TM1.

I don't know how to tell you this, but I honestly can't recall a single major release since at least 9.0 that would not introduce at least one change to existing and relied upon functionality, either on purpose, or as a defect. That probably goes for many of the FixPacks too. There is just no way one can do an upgrade without a full regression test and often a rewrite of some bits. Sometimes a planned upgrade is unworkable or has to be rolled back after the fact. IBM are not Microsoft and have much less incentive in investing time and money in ensuring full backward compatibility. As the number of lines of code grows (probably in line with Moore's law - just compare the size of install packages today and 10 years ago), so does the effort that would have to be put into testing every possible scenario. Customers, by taking a lot of that testing effort on their shoulders, can get more frequent software updates.

qml,

Yes, I know. It was wishful thinking and a little venting, this one really being an oddity, but c'est la vie.

Thanks again to everyone!

Ty

declanr wrote:

PavoGa wrote:

• using = N: notation
  converting the value to be stored to a string
  ['Director_Subset_Flag'] = 99;
  ['Director_Subset_Flag'] = N:99;

Try:

Code: Select all

['Director_Subset_Flag']=S: '99';

This worked. Thanks. Really odd though.. Drove me crazy initially