Re: To use or not to use persistent feeders?
Posted: Wed Dec 06, 2017 3:48 pm
Steve here is my detailed test:
Delete the rule from Server explorer.
Check the Rux is deleted from the server data folder.
Delete all connected blb, and feeder file which attached to the cube.
Restart the service and afterwards the feeder file came back for the purely plain number input containing cubes.
Further more all cube and I checked and all feeder has on the left side the limitation to the calculating version only!
Thanks for your advice, I check further maybe I missed something.
On the TI process side the problem is in the details as always.
I need the online calculation because we do scenario modelling as we generate several deltas based on top of the base case by different parameters table, which mean if a parameters change I need to recalculate several parallel version, if I would replace this by process the user should trigger after every parameter change which is totally non sense if we using TM1. This would totally kill the flexibility of the model and the this is the backbone of the system requirement.
I need the drop feeder when for example the users create new use cases because then I have to trigger the feeders from the base case to the new use case as well so I drop the rule and reattach it. This is not happen every day regularly but when the planning is ongoing could be done several time a day.
Anyway thanks for your other suggestion.
Delete the rule from Server explorer.
Check the Rux is deleted from the server data folder.
Delete all connected blb, and feeder file which attached to the cube.
Restart the service and afterwards the feeder file came back for the purely plain number input containing cubes.
Further more all cube and I checked and all feeder has on the left side the limitation to the calculating version only!
Thanks for your advice, I check further maybe I missed something.
On the TI process side the problem is in the details as always.
I need the online calculation because we do scenario modelling as we generate several deltas based on top of the base case by different parameters table, which mean if a parameters change I need to recalculate several parallel version, if I would replace this by process the user should trigger after every parameter change which is totally non sense if we using TM1. This would totally kill the flexibility of the model and the this is the backbone of the system requirement.
I need the drop feeder when for example the users create new use cases because then I have to trigger the feeders from the base case to the new use case as well so I drop the rule and reattach it. This is not happen every day regularly but when the planning is ongoing could be done several time a day.
Anyway thanks for your other suggestion.