Page 1 of 1

TI gripes - no return code, functions tab specific

Posted: Tue Nov 10, 2009 8:52 pm
by John Hammond

Code: Select all

------------------------------------- prolog tab --------------------


DimensionElementComponentAdd('dimChartOfAccounts', 'Motor Vehicles', 'John Hammond', 1.00);

------------------------------------- metadata tab --------------------

testit = DimensionElementComponentAdd('dimChartOfAccounts', v1,  v1 | v2, 1.00);
xyz = STR(testit,6,0) ;

------------------------------------- data tab --------------------

asciioutput('c:\test.csv',v1 );
asciioutput('c:\test.csv',v2 );
asciioutput('c:\test.csv', '-----------------------------------'  | xyz | '--------------------------------' );

This was very simple code to go thru a list of parent entries in the .csv input file and insert a child beneath them with a suffix.

1. When I used DimensionElementComponentAdd in the Data tab it did not work - but it did ni the Metadata tab.
2. When I used asciioutput in the Metadata tab it did not work - but it did in the data tab.
3. When I continue to try and add multiple elements as in the prolog - which I run again and again without error - I would expect there to be some kind of error mechanism to complain that I was trying to add duplicate elements.
However when I use testit to check if there is a return code then I always get I.

The problem that I might enter an invalid parent is correctly flagged in the message log, however.

Does anyone know whether TM1 has some sort of return code system and why and what functions are tab specific.

Thanks for your help.

Re: TI gripes - no return code, functions tab specific

Posted: Tue Nov 10, 2009 10:13 pm
by Alan Kirk
John Hammond wrote:

Code: Select all

------------------------------------- prolog tab --------------------


DimensionElementComponentAdd('dimChartOfAccounts', 'Motor Vehicles', 'John Hammond', 1.00);

------------------------------------- metadata tab --------------------

testit = DimensionElementComponentAdd('dimChartOfAccounts', v1,  v1 | v2, 1.00);
xyz = STR(testit,6,0) ;

------------------------------------- data tab --------------------

asciioutput('c:\test.csv',v1 );
asciioutput('c:\test.csv',v2 );
asciioutput('c:\test.csv', '-----------------------------------'  | xyz | '--------------------------------' );

This was very simple code to go thru a list of parent entries in the .csv input file and insert a child beneath them with a suffix.

1. When I used DimensionElementComponentAdd in the Data tab it did not work - but it did ni the Metadata tab.
That's correct, at least in 9.1 and presumably other versions as well.

However that's the metadata tab's purpose. You can get away with doing metadata actions on the Prolog or Epilog as well as well (or at least some of them) but at the end of the Metadata tab the system will do all of the necessary compilation and saving of the dimensions, attributes, etcetera - in short, it updates the database's metadata - which means that the cubes will then be ready to receive values in the Data tab. This doesn't happen in the Data tab itself. At least, that is what we've surmised by trial and error over the years; the documentation is its usual helpful self on such issues. :roll:

In other words, if it relates to writing data from the data source to the cube, it goes on the Data tab. If it involves updating cube or dimension structures, Metadata tab. Both tabs loop through the whole data source once (if there's any code in the relevant tab).

That's a better guide than trying to identify which individual functions should be used on which tab.
John Hammond wrote: 2. When I used asciioutput in the Metadata tab it did not work - but it did in the data tab.
Either there was no data to process on the time that you attempted that, or there may have been a bug in your code, because AsciiOutput does work on any of the tabs. One thing to watch out for, though; if you have an AsciiOutput on (say) the Metadata tab, each row that you process from the data source will append a new line to that output file. That's not a problem.

However if you AsciiOutput to a text file of the same name in a later tab (either the Data or Epilog tab) that output will blow away the file that you created on the Metadata tab. In other words, each tab will overwrite any output file that was created by an earlier tab. If you need to output from multiple tabs in your process, be sure to use different file names.
John Hammond wrote: 3. When I continue to try and add multiple elements as in the prolog - which I run again and again without error - I would expect there to be some kind of error mechanism to complain that I was trying to add duplicate elements.
However when I use testit to check if there is a return code then I always get I.
I know that DimensionElementComponentAdd is supposed to be a function, and functions are supposed to return values, but... don't rely on return values from any function unless the documentation tells you that you can. Unless Iboglix explicitly states that a return value has a particular meaning, then (a) it may not have, and (b) there's no guarantee that they won't change what that meaning is in a future version without mentioning it.

It appears that if the element already exists in the consolidation then DimensionElementComponentAdd just ignores it. (Again tested in 9.1.) However this is consistent with the behaviour of most metadata functions, and is in fact quite useful. For example if you're updating a chart of accounts you don't need to be receiving error messages from the DimensionElementInsert function to tell you that elements already exist; if they do, they're just ignored, if they don't, they're added. It appears to be a similar sort of thing with the DimensionElementComponentAdd function. If it were otherwise the only way you could avoid the error would be by doing a DimIx test (ElIsComp in your case) to see whether the element already existed before you tried to add it. The way it has been implemented is faster, requires less coding on our part, and avoids unnecessary errors.

Good gods, did I just praise the way that Applix implemented something?!

Let me qualify that before the long term membership swoons; I grant you that they probably could have coded the function so that it returned different codes depending on the result, but I don't think it's that critical; if you really need to check whether the element that you're adding is already there and write to an error log you can use ElIsComp in conjunction with either ItemReject or an AsciiOutput.
John Hammond wrote: The problem that I might enter an invalid parent is correctly flagged in the message log, however.

Does anyone know whether TM1 has some sort of return code system
{Cough}, I'll leave that issue for your namesake Mr. Hobson... :lol:
John Hammond wrote: and why and what functions are tab specific.
There aren't any that I can think of which really are tab specific as such, though they may not always work as advertised on all tabs. You can determine that from the context of what the function is supposed to do. As I said if you're processing from a data source you should keep metadata actions on the metadata tab. If you're not (data source of "None"), I'd generally only do them on the Prolog tab.

Re: TI gripes - no return code, functions tab specific

Posted: Wed Nov 11, 2009 7:55 am
by John Hammond
Mr T - It's a shame you don't like flying because if you came over to England I'd give you as many Snickers Bars as you wanted. :)

Alan, seriously, thank you for giving me the time to produce such an in depth answer. As someone mentioned a definitive guide for TM1 could make someone a fortune. You were right about asciioutput but how confusing its behaviour is.

I can see the philosophy now - keep it simple and concentrate on the most likely use, but they could still retrofit return codes.

Re: TI gripes - no return code, functions tab specific

Posted: Wed Nov 11, 2009 11:02 am
by John Hammond
This is the correct way to use DimensionElementComponentAdd

Code: Select all

IF (DTYPE('dimChartofAccounts',V1)  @= 'C' );
   testit = DimensionElementComponentAdd('dimChartOfAccounts', v1,  v1 | v2, 1.00);
   asciioutput('c:\pAdd_CoA_Dummy_Elements_Success.txt', V1 |  ' child inserted  '  |  v1 | v2 );
ELSE ; 
   asciioutput('c:\pAdd_CoA_Dummy_Elements_Failure.txt', V1 |  ' is not a Consolidation ' );
ENDIF ;
IMPORTANT GRIPE: DimensionElementComponentAdd WILL TAKE AN N LEVEL ELEMENT AND TURN IT INTO A CONSOLIDATION IF YOU ASK IT TO INSERT A CHILD.

This is really a bug / unacceptable behaviour by TM1 since by promoting an N level to a consolidation you will lose data from your cube.

Be Warned!

Re: TI gripes - no return code, functions tab specific

Posted: Wed Nov 11, 2009 9:04 pm
by Alan Kirk
John Hammond wrote:This is the correct way to use DimensionElementComponentAdd

Code: Select all

IF (DTYPE('dimChartofAccounts',V1)  @= 'C' );
   testit = DimensionElementComponentAdd('dimChartOfAccounts', v1,  v1 | v2, 1.00);
   asciioutput('c:\pAdd_CoA_Dummy_Elements_Success.txt', V1 |  ' child inserted  '  |  v1 | v2 );
ELSE ; 
   asciioutput('c:\pAdd_CoA_Dummy_Elements_Failure.txt', V1 |  ' is not a Consolidation ' );
ENDIF ;
IMPORTANT GRIPE: DimensionElementComponentAdd WILL TAKE AN N LEVEL ELEMENT AND TURN IT INTO A CONSOLIDATION IF YOU ASK IT TO INSERT A CHILD.

This is really a bug / unacceptable behaviour by TM1 since by promoting an N level to a consolidation you will lose data from your cube.

Be Warned!
Sorry, I should have warned you about that one.

It's a known issue. I reported it to Applix I have no idea how long ago (unfortunately I didn't store the date in my copy and the old Applix forum doesn't show posting dates either, but we're talking years ago now) as issue 363783. I don't have any record of what happened to it after that, though "Transferred to Engineering" followed by "Lost In Space" are pretty fair bets.

Anyway, I've re-reported it to IBM as SR 86622 999 616.

(I appended a request that the function return different values depending on the outcome of the insertion as well, but don't hold your breath on that one.)