IBM Data and AI

Welcome to the IBM Data and AI Ideas Portal for Clients!

We welcome and appreciate your feedback on IBM Data and AI Products to help make them even better than they are today!
Before you submit an idea, please perform a search first as a similar idea may have already been reported in the portal. If a related idea is not yet listed, please create a new idea and include with it a description which includes expected behavior as well as why having this feature would improve the service and how it would address your use case.
IBM Employees:
  • Our team welcomes any feedback and suggestions you have for improving our offerings / products! This forum allows us to connect your offering / product improvement ideas with IBM product and engineering teams.

  • If you have not registered on this portal please click on the following link and register. To complete registration you will need to open the email you will receive from Aha to confirm your identity.

Additional Information:
  • The shorter URL for this site is:

  • To view our roadmaps:

  • Reminder: This is not the place to submit defects or support needs, please use normal support channel for these cases

  • Please do not use the Ideas Portal for reporting bugs - we ask that you report bugs or issues with the product by contacting IBM support.

Database sends (DBS) should fail

In Pafe when a user executes a DBS against a cell which is not writeable the formula returns the value of the cell. Not writeable means C level, read-only access, write access but locked.

This is counter productive, the job of the formula is to send data to TM1 and report success or failure.

There is now no difference in cell state between the formula successfully working or not. This means that in Pafe every DBS execution needs full reconciliation post send to test for success, this should not be required.

In the legacy clients sending to a non-writeable cell meant that the formula showed an error, a clear and obvious indication of a fault.

Imagine designing TI processes such that they always report success and suppress all error messages. Makes no sense, the same logic as to why a TI process has errors and so forth applies to DBS formula.

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Jul 3 2020
  • Needs more information
Who would benefit from this IDEA? Users would benefit as they can tell what they are doing is working. BAU temas would benefit as they will get fewer queries about why reports are showing incorrect values. TM1 would benefit from the lack of reputational damage from having illogical / dangerous functionality.
How should it work?

Sending values to a non-writeable cell should retun #N/A giving the user a clear indication that there is an issue with their access.

Idea Priority High
Priority Justification Ongoing risks to system integrity plus request from high value customer.
Customer Name InfoCat
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    13 Oct 02:09pm

    Hi Paul, Hope all is well in these challenging times?

    This RFE is now set to "Needs more information", is some kind of input required from the community?

    Just to reiterate the comments from others here and on TM1 Forum, irrespective of the reasons that prettiness was chosen over usefulness, the function really needs to generate an error if the write is not possible.

    If we were having this conversation about why CellPutN in a TI function should generate errors when it fails, I think it would be a very short conversation. DBS / DBSW fulfills the same role as CellPutN/S

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    18 Sep 06:03am

    Users should not need to try remedy a defect in a function that previously worked and provided clear feedback of any issues in encountered during the send.

    Mitigation through the use of macros and/or other functions may lead to further degradation of integrity and trust in the system.

    It is critical to have a working function that consistently succeeds or fails as the case may be.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    18 Sep 01:48am

    In practical use of the product effectiveness is far more important than consistency. The sole purpose of a DBSx function is to send data. The user's principal interest - indeed only interest - is in whether that data HAS, in fact, been sent. If they have a large number of DBSx functions on a sheet, they need to have"at a glance" visibility of which sends have succeeded and which have failed. If they do NOT have that visibility then either:
    (a) They have to waste time creating conditional formatting to show variances between the source values and the values that the DBSx cell is reporting (and let's be brutally honest, Excel conditional formatting is far from bullet proof) OR
    (b) They need to write formulas or manually compare the DBSx value with the source values.

    If they fail to do that then there is the possibility of the user BELIEVING that the data has gone up, when it has not. This can lead to incorrect data in the system, which can lead to mistaken conclusions, which can lead to bad decisions, which can lead to managers claiming that they can't trust TM1.

    And all this because the send function won't display an error saying "Hey, this data did not actually go up".

    From where I sit in an "in the field" admin's chair, that's a pretty high potential price to pay for the orderliness and prettiness of "consistency".

  • Admin
    Paul Glennon commented
    17 Sep 07:42pm

    PA for Excel will degrade dbs* to a read in all cases for consistency. Perspectives itself was not consistent in the implementation across these functions as in 2/3 operational cases it would degrade to a read, while 1/3 would degrade to fail. part of the discrimination in perspectives is along the lines of dbs vs dbsw; PA for Excel treats all wan vs non-wan functions the same, and i think we've aligned the addin to the majority case.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    6 Jul 09:00am

    Providing the correct visual feedback to an end user is imperative. Given this worked in an old release (Perspectives), I strongly support such functionality being available in the new Excel front end.

NOTICE TO EU RESIDENTS: per EU Data Protection Policy, if you wish to remove your personal information from the IBM ideas portal, please login to the ideas portal using your previously registered information then change your email to "anonymous@euprivacy.out" and first name to "anonymous" and last name to "anonymous". This will ensure that IBM will not send any emails to you about all idea submissions