Use DBRW to write values to cube

[hyunjia]

HI guys

I have always been using DBRW to return value from a cube, however as I read from the tm1 reference which is bundle with tm1 installation, it saids "the DBRW function can also be used to write values to the specified cube" ?

Have any one use this feature or any example on updating cube value by DBRW ? Does it mean that I may accidentlly update the cube when I am using DBRW ?


Thanks

[Alan Kirk]

I have always been using DBRW to return value from a cube, however as I read from the tm1 reference which is bundle with tm1 installation, it saids "the DBRW function can also be used to write values to the specified cube" ?

Have any one use this feature or any example on updating cube value by DBRW ? Does it mean that I may accidentlly update the cube when I am using DBRW ?

1/ Create a view with all of the elements at N level.
2/ Slice it into an Excel sheet.
3/ Punch a number into the cell.
4/ Watch the number be immediately written to the cube on the server.

It's one of TM1's key selling points so yes, it's a fair bet that one or two people have used this feature over time.

If you want to prevent someone from accidentally writing that way:
1/ Use security; or
2/ Make sure that the slice contains at least one consolidation. You can't directly write to a consolidation, although doing a Clear using data spreading is an exception to this. (Though so is writing to a string rather than numeric element.)

[hyunjia]

I have always been using DBRW to return value from a cube, however as I read from the tm1 reference which is bundle with tm1 installation, it saids "the DBRW function can also be used to write values to the specified cube" ?

Have any one use this feature or any example on updating cube value by DBRW ? Does it mean that I may accidentlly update the cube when I am using DBRW ?

1/ Create a view with all of the elements at N level.
2/ Slice it into an Excel sheet.
3/ Punch a number into the cell.
4/ Watch the number be immediately written to the cube on the server.

It's one of TM1's key selling points so yes, it's a fair bet that one or two people have used this feature over time.

If you want to prevent someone from accidentally writing that way:
1/ Use security; or
2/ Make sure that the slice contains at least one consolidation. You can't directly write to a consolidation, although doing a Clear using data spreading is an exception to this. (Though so is writing to a string rather than numeric element.)

In that case, Can I avoid accidentally write back by using View function to retrieve data instead of cube instance name ?

[hyunjia]

I have always been using DBRW to return value from a cube, however as I read from the tm1 reference which is bundle with tm1 installation, it saids "the DBRW function can also be used to write values to the specified cube" ?

Have any one use this feature or any example on updating cube value by DBRW ? Does it mean that I may accidentlly update the cube when I am using DBRW ?

1/ Create a view with all of the elements at N level.
2/ Slice it into an Excel sheet.
3/ Punch a number into the cell.
4/ Watch the number be immediately written to the cube on the server.

It's one of TM1's key selling points so yes, it's a fair bet that one or two people have used this feature over time.

If you want to prevent someone from accidentally writing that way:
1/ Use security; or
2/ Make sure that the slice contains at least one consolidation. You can't directly write to a consolidation, although doing a Clear using data spreading is an exception to this. (Though so is writing to a string rather than numeric element.)

In that case, Can I avoid accidentally write back by using View function to retrieve data instead of cube instance name ?

It seems to be a stupid question , there should not be any updating action as long as I use hand-craft DBRW instance.

[Alan Kirk]

In that case, Can I avoid accidentally write back by using View function to retrieve data instead of cube instance name ?

I suggest looking in the Reference Guide for what the View function does. It has nothing to do with reading or writing.

[Alan Kirk]

It seems to be a stupid question , there should not be any updating action as long as I use hand-craft DBRW instance.

Nor does the functionality of DBRWs depend on whether they are generated in a slice or "hand crafted".

[jstrygner]

Looking at your question I am guessing you are also not aware of DBR function, but this does not mean DBRW stands for DBReadWrite and DBR stands for DBRead. This other one will also allow you both reading and writing, no matter how you generate it in your report (please look into documentation or search this forum for difference details between those functions).

Sometimes I have a need of displaying a value that is stored in one of the cubes, but want to prevent it from being changed accidently through overwriting. Example could be a Current month parameter. In such a case I could use DBR function, but instead of using this:

Code: Select all

=DBR("ServerName:Parameters","Current Month","String Value")

I would apply this:

Code: Select all

=""&DBR("ServerName:Parameters","Current Month","String Value")

Writing over this cell will not send the value to TM1, it will only change the cell value for this report. This way it is safe from accidential change even by ADMIN group user (where security would not be enough).

So it is possible to make it artificially READ only. But replacing =DBRW() with =""&DBRW() for the report values section will cause querying TM1 server cell by cell each value separately, which is not a good practice and I would not recommend it to be applied for such a reason.

If your report is used via TM1 Perspectives (Excel Add-In) you can apply Excel functionality of cell protection.

For TM1Web you can additionally set a property that in Web interface the report is read-only, even if using such a report in TM1 Perspectives would have Read/Write functionality.

Hope that helps

[hyunjia]

Looking at your question I am guessing you are also not aware of DBR function, but this does not mean DBRW stands for DBReadWrite and DBR stands for DBRead. This other one will also allow you both reading and writing, no matter how you generate it in your report (please look into documentation or search this forum for difference details between those functions).

Sometimes I have a need of displaying a value that is stored in one of the cubes, but want to prevent it from being changed accidently through overwriting. Example could be a Current month parameter. In such a case I could use DBR function, but instead of using this:

Code: Select all

=DBR("ServerName:Parameters","Current Month","String Value")

I would apply this:

Code: Select all

=""&DBR("ServerName:Parameters","Current Month","String Value")

Writing over this cell will not send the value to TM1, it will only change the cell value for this report. This way it is safe from accidential change even by ADMIN group user (where security would not be enough).

So it is possible to make it artificially READ only. But replacing =DBRW() with =""&DBRW() for the report values section will cause querying TM1 server cell by cell each value separately, which is not a good practice and I would not recommend it to be applied for such a reason.

If your report is used via TM1 Perspectives (Excel Add-In) you can apply Excel functionality of cell protection.

For TM1Web you can additionally set a property that in Web interface the report is read-only, even if using such a report in TM1 Perspectives would have Read/Write functionality.

Hope that helps

Thanks , That is a brilliant approach.