Skip to Main Content
IBM Data and AI Ideas Portal for Customers

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Post your ideas

Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,

  1. Post an idea

  2. Upvote ideas that matter most to you

  3. Get feedback from the IBM team to refine your idea

Help IBM prioritize your ideas and requests

The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The product management team will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.

Receive notification on the decision

Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.

Additional Information

To view our roadmaps:

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

IBM Employees:

The correct URL for entering your ideas is:

Status Under review
Workspace Planning Analytics
Created by Guest
Created on Jul 3, 2020

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.

Needed by Date Jul 3, 2020
  • Guest
    Sep 9, 2021

    +1 for this (irrespective of whether using DBS or DBSW). Having just tested with perspectives I disagree with the comment 17th September. I found Perspectives to be consistent in all 3 scenarios. In perspectives, the user will naturally use the workbook in manual calc mode (although auto calc yields the same behaviour here). They will load data on the sheet via an F9 (or shift F9) refresh (often controlled by an IF formula against a "Send Y or N" type reference control cell to avoid inadvertent sends when re-opening the book or refreshing other formula). Perspectives displays N/A consistently for cube security set to read only, write cube access but cell security read only, and c level. I didn't test element security. The only way I could make perspectives perform differently was if simply pressing enter after inputting a simple DBS formula when it would default to a read for all three scenarios. This isn't what power users who have write access do, they don't load single cells worth of data at a time via a workbook and if they did they would be putting an IF statement around it to control the load. I note that in this single cell case the formula output by perspectives would update to an N/A next time the worksheet was F9 refreshed. Perhaps this RFE could be reassessed as I don't believe PAFE has been based on the majority case, but instead a niche case that would never have been noticed in the real world.

  • Guest
    Jan 20, 2021

    I have just come off another call identifying what part of a user's DBS range failed to send. I've been working with TM1 since the Applix days and yet still took me 10 mins to work out which lines in the various tabs were failing. Total time spent between the user and myself is close to an hour in total for what historically was blatantly obvious instantly to the user through the error status of the function. T

    Total waste of time and confidence sapping for the user who is transitioning from Hyperion.

    It annoyed me so much I came back to see what the status of this ticket was at but note it's still showing as "Needs more information" three months later. Can we clarify what further information is required to progress please?

  • Guest
    Oct 13, 2020

    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

  • Guest
    Sep 18, 2020

    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.

  • Guest
    Sep 18, 2020

    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".

  • Guest
    Sep 17, 2020

    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.

  • Guest
    Jul 6, 2020

    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.