TM1 Forum

Hi
I am wondering, if I run a TI process that amends figures on N-level in my cube, when would TI commit the changed values? For example, let's say I loop through all N-level real values of my cube and increase each of them by 10% using a CellPutN formula in TI, immediately after the CellPutN I read the C-level total in all dimensions (the N-level elements aggregate into the total) via a CellGetN formula, would I get the increased total with every read on top level? Or does the total only change after the TI process finished, i.e. values are only committed in the end?

cheers
Marc

Hi Marc,

Immediately. If that's not what you want then you might be able to use BatchStart to get around this, I'm not sure.

Note "commit" is a slightly ambiguous term though. It will be in the cube as soon as it is written, but it will not be committed to disk until a save data all is completed or the server is stopped. This means that if the server crashes and you had logging turned off, then the value will not be remembered.

Martin

Marc wrote: I am wondering, if I run a TI process that amends figures on N-level in my cube, when would TI commit the changed values? For example, let's say I loop through all N-level real values of my cube and increase each of them by 10% using a CellPutN formula in TI, immediately after the CellPutN I read the C-level total in all dimensions (the N-level elements aggregate into the total) via a CellGetN formula, would I get the increased total with every read on top level? Or does the total only change after the TI process finished, i.e. values are only committed in the end?

Assuming that you aren't using batch updates (which we'll take as a given) then yes, the value will be changed as soon as you execute the CellPutN. That means that if you do a CellgetN on the top level consolidation, you'll get the new Total. That having been said, doing that is something that you should avoid as it will jack up your processing time by (potentially) a substantial margin since the consolidation would need to be recalculated for each read.

{Edit: Martin beat me to it...}

I am using a CellPutS in a TI process to write values to a control cube and if I refresh my cube view (from a different instance of architect), i do not see the updated values until the TI process completes.

If I put a savedataall after the cellputs, then the values in the control cube are updated while the TI is running.

Any ideas on how to not use the savedataall and be able to view the data while the TI is running?

ajain86 wrote:I am using a CellPutS in a TI process to write values to a control cube and if I refresh my cube view (from a different instance of architect), i do not see the updated values until the TI process completes.

If I put a savedataall after the cellputs, then the values in the control cube are updated while the TI is running.

Any ideas on how to not use the savedataall and be able to view the data while the TI is running?

This is (or was) an older thread but the comments from Martin and Alan above aren't strictly correct for versions 9.5.x (and I am pretty sure 9.4.x too). Each data transaction is committed immediately to the model stored in memory and to disk on a save data command or planned server shutdown (meta data changes are committed to disk immediately when the change is made in memory and don't wait for the save data command; "meta data" = dimension changes, subsets, views, application entries, processes, etc. Pretty much anything outside cube data.)

The difficulty is in understanding what TM1 sees as a "transaction". In the case of entering into the cube viewer or typing a value over a DBRW cell in Excel a data transaction is changing a single cell value. In the context of the API it would be similar being a CubeCellValueSet, however TM1 sees all changes in a TI as a single transaction, thus all data changes within a TI (or actually a chore or series of TIs called via ProcessExecute from a single process) are implicitly batched and committed in one go. While the TI is running it holds a updated copy of the data model including the changes, other users cannot see the changes until the process finishes (or in the case of a chore until the last process in the chore finishes) and the data changes are committed. If the process needs to rollback or encounters a major error and aborts, then the changes aren't committed and get blown away.

So the answer is simply that what you are seeing is expected behaviour. If you have a long running process none of the data changes will be visible to other threads until the process completes.

I sincerely hope that you are NOT placing a SaveDataAll command in the data tab. Although this will force commitment of data to the model in memory and to disk within the process (in effect closing off the transaction and starting a new one with each record) and make your data changes visible this could have disastrous consequences for performance and stability if you have any more than a small handful of users on the system making data updates. This is because SaveDataAll places a temporary write lock on all objects on the server while TM1 figures out which objects have changes and need to be updated on disk before releasing the lock on the objects that don't need updating on disk and then saving each object with changes to disk (one at a time sequentially) and releasing the lock on each as each save to disk is completed. If changes to the model are being made by other threads (users or other processes) then the SaveDataAll will encounter contention and need to rollback.

It is recommended practice to only execute a SaveDataAll in an independent process in a separate execution window outside of any process or chore that has made any data changes in order to minimise the risk of any contention. To place a SaveDataAll not just on the epilog of a process making data changes but on the data tab is just asking for trouble.

Thanks for the confirmation.

I was confused when I read through Martin and Alan's comments. I read their comment as saying that one could see the impact of a data change while the TI was running.

Old thread but still very useful. Think i need to add that (in 9.5.2 at least) if a chore runs that alters dimension structures, even if another part of the chore unrelated to the dimension build itself has just minor errors (eg. can't update an alias due to duplicates) the entire chore is rolled back. So in an instance such as mine where i know a small number of values will create duplicate errors and i'm happy to ignore them, i have to write around the error to handle it rather than just leave it alone.