DBS should fail, hard!

[Steve Rowe]

Hi, if you agree with this RFE please take the time to vote.

https://ibm-data-and-ai.ideas.aha.io/ideas/PAOC-I-331

I bet I don't get 10 likes!

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.

TIA for anyone taking the time to vote.

[gtonkin]

Sounds like it is borked.

Here's the link if anyone needs it:

+1

[Wim Gielis]

I bet I don't get 10 likes!

Currently, you have 8 so 2 remaining.

[Alan Kirk]

I bet I don't get 10 likes!

Currently, you have 8 so 2 remaining.

I've already cast mine...

[Alan Kirk]

I bet I don't get 10 likes!

Currently, you have 8 so 2 remaining.

I've already cast mine...

14 and counting. When does our bet money arrive in our accounts?

[Wim Gielis]

14 and counting. When does our bet money arrive in our accounts?

When IBM have implemented it

[HighKeys]

14 and counting. When does our bet money arrive in our accounts?

When IBM have implemented it

So never

[Alan Kirk]

So, here's the response to this one:

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.

Sigh. What can you say? To me this has all the hallmarks of someone who has never used the product operationally. Again in my view, it suggests a fixation on "neatness" over effectiveness. It doesn't matter if Perspectives was inconsistent, especially if the inconsistency was in the non-WAN functions (because... who uses them for a numeric send anyway?). The point is that if you have a function whose purpose is to send, you need a clear, visual indicator of whether that send was successful or not. If the formula doesn't provide it itself then your only option is to go to conditional formatting and that is not exactly the most time-effective workaround for ad hoc loads. Of course, in IBM-vision, I suppose that nobody does that and they all create immaculately formatted worksheets for any interaction with the product. See also, "has never used the product operationally".

[Alan Kirk]

So, here's the response to this one:

PA for Excel will degrade dbs* to a read in all cases for consistency. ...

Sigh. What can you say? To me this has all the hallmarks of someone who has never used the product operationally.

Ooooh kay, this is what I posted as a comment, which will probably have no impact whatsoever, but at least I said it:

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

[gtonkin]

Thanks Alan - added my 2 cents worth too as we ran into this again this week.

To mitigate this, as you and others have mentioned, you need to do all sorts of reads and checks to test if what you have sent actually got sent.
The risk here is you now introduce macro code and other nonsense which is error prone and makes support and maintenance more onerous.

Certainly hope it gets sorted as new-to-TM1 developers will certainly get caught out.