Database sends (DBS) should fail

+1 for this (irrespective of whether using DBS or DBSW). Having just tested with perspectives 2.0.9.2 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.

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?

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

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.

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

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.

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.