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

This portal is to open public enhancement requests against products and services offered by the IBM Data & AI organization. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

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:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

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

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

IBM Data & AI Roadmaps ( - Use this site to view roadmaps for Data & AI products.

IBM Employees should enter Ideas at

Status Not under consideration
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.