Bug in TI Process order?

[Steve Rowe]

I think this is a small bug seen in CX 10.2 something or other
If I create a consolidation in the prolog and put it in a view for the datasource of that TI then the process aborts since the consolidation is not in the dimension by the time the MD / D tabs access the view.

If I Process Break at the end of the TI I can see that the view gets created without issue.

Isn't this wrong? It means the TI is accessing the view before the prolog completes / commits so there seems to be some kind of ordering problem here.

Interestingly using the direct function doesn't resolve this issue and I had to step out into a sub TI to build the consolidation.

I expect TI has always behaved like this and just not noticed or thought about what was going on.

[qml]

TI commits metadata changes only once - between Metadata and Data tabs. It does not do it at the end of Prolog and it's been that way since I can remember. It's easy to test. Put one DimensionElementInsert call in Prolog and one in Metadata. If you then add a ProcessQuit call anywhere before the Data tab then neither change will be committed. If you add a ProcessQuit call anywhere after the Metadata tab then both changes will be committed.

[Steve Rowe]

I'm not sure that it is 100% the same thing Kamil.

I thought that changes made in the "local to the TI" dimension were available to that TI for the life of the TI irrespective of when the changes are committed back to the system as whole.

For example

If I populate a text file with 10 rows of the same value, use this as a datasource with this Metadata as shown below

Code: Select all

If(Dimix('A' , v1)=0);
   DimensionElementInsert('A' , '' , v1 , 'N');
Else;
  asciioutput('b.cma' , 'a');
EndIf;

Then I get 9 rows in my b.cma file.

So there is a local copy of the dimension that the TI is using before fully committing.

I guess it has to be fully committed before being used against data but I can't quite convince myself that it has always been like that....Probably just encountering a nuance that I'd just worked around previously....

Hope you had a good break and the New Year treats you well.

Cheers,

[lotsaram]

I guess it has to be fully committed before being used against data but I can't quite convince myself that it has always been like that....Probably just encountering a nuance that I'd just worked around previously....

Convince yourself. That's how it is.

What Kamil said is correct, there isn't a separate prolog and metadata dimension commit, only the one at the end of metadata. The data source of a TI process can only be from the base model so if you have edited a dimension in the prolog then any changes can't be part of the assigned data source since changes exist only in the shadow copy and not in the base model. So a support style answer would be "this is expected behaviour".

If you made the prolog changes to insert the consolidation using the DimensionInsertDirect functions then I would guess it should work though as this takes the shadow dimension copy out of the equation.

[Alan Kirk]

I'm not sure that it is 100% the same thing Kamil.

I thought that changes made in the "local to the TI" dimension were available to that TI for the life of the TI irrespective of when the changes are committed back to the system as whole.

You're right... but so is Kamil. Lotsa beat me to this but I'll just add one other thing; "metadata ain't always metadata". There has always been a difference between subsets and dimension updates. Specifically, subsets do not need to go through the Metadata commit barrier to be updated. If they did it would make it damn near impossible to dynamically create a data source without having calls to other processes (which didn't exist back in version 8).

Proof?
I created a dimension with two elements, Element 1 and Element 2.

Then I created two processes. All of the code is in the Prolog of both processes. Here is the code of process 1:

Code: Select all

SC_DIM = 'zTestDim';
SC_SUBSET = 'Sample Subset';

SubsetCreate( SC_DIM, SC_SUBSET);
SubsetElementInsert( SC_DIM, SC_SUBSET, 'Element 1', 1);

DimensionElementInsert( SC_DIM, '', 'Total Elements', 'C');

ExecuteProcess ('zTest2');

And here is the code of process 2:

Code: Select all

SC_LOG = '\\tm1\tm1\Temp\SubsetVsElementTest.txt';

SC_DIM = 'zTestDim';
SC_SUBSET = 'Sample Subset';

AsciiOutput ( SC_LOG, 'The dimension ' | SC_DIM | ' contains ' | NumberToString(DimSiz ( SC_DIM) ) | ' ELEMENTS.' );

If ( SubsetExists ( SC_DIM, SC_SUBSET) = 1);
    sMsg = 'The subset exists and has ' | NumberToString ( SubsetGetSize( SC_DIM, SC_SUBSET) ) | ' elements.';
Else;
    sMsg = 'The subset does not exist.';
EndIf;

AsciiOutput ( SC_LOG, sMsg );

And here is the output:

Code: Select all

"The dimension zTestDim contains 2 ELEMENTS."
"The subset exists and has 1 elements."

OK, so as I said, the test dimension had two elements before I did the DimensionElementInsert. When it calls out to the second process, that process reports... two elements. That's because the DimensionElementInsert will not take effect (for the purposes of the system as a whole) until the Metadata commit is done. (It obviously exists in the in memory private copy of the dim so anything that I do in process 1 would know about it, but a separate process won't.)

The subset didn't exist until I did the SubsetCreate command in the first process.

Yet the second process not only knew that it was there but correctly identified how many elements it had.

Conclusion? Subsets get updated immediately; they don't need to wait for the Metadata commit. Elements, on the other hand, are in a different boat, at least if the non-Direct functions are used. Obviously by the time the Metadata commit happens, it is too late to include the new element in your data source because the data source will have already iterated once, on the Metadata tab.