lotsaram wrote: ↑
Tue Nov 03, 2020 10:14 am
I agree. If you have a reproducible test case then raise as a defect. There's no way this shouldn't work for MTFeeders.
(and this is how I write my feeders).
We intend to raise the issue with IBM asap. We think we've skated by until now because of persistent feeders, but our model uses a continuous timeline and had just added the periods for another fiscal year when this manifested itself in testing some new functionality.
Continued testing this issue yesterday and here are some more observations. Not conclusively proven to the Nth degree, but I want to get this out in case people start running into feeder issues in their models with this version. Important to note, we do not
have this problem in cubes where the calcs are fed from user input cells and MTFeeders=F.
We see this work:
Code: Select all
# [B] & [C] are fed if [A] is not rule driven and MTFeeders=F
[A] => [B], [C];
This does not work now:
Code: Select all
# cube1 feeder
[A] => DB(cube2, elem1, elem2, [B]);
# cube2 feeder
[B] = N:DB(cube1, elem1, elem2, [A]);
# [C] gets fed. [D] will not be fed.
[B] => [C], [D];
# [D] gets fed if the feeders are structured this way:
[B] => [C];
[B] => [D];
# oddly enough, this appears to work:
[B] => DB(cube2, !elem1, !elem2, [C]), DB(cube2, !elem1, !elem2, [D]);
It does not matter if MTFeeders=F or T. Fully qualifying the elements with dimension names makes no difference.
Running CubeProcessFeeders does absolutely nothing. Server restarts, removing and resaving the rules, or making a new entry into [A] accomplish nothing. Zero, zilch so far. Only splitting the feeder, or possibly switching all internal feeders to DB(), resolves it.
Das ist schlecht.