DBS should fail, hard!

Suggest and discuss enhancements for TM1
Post Reply
User avatar
Steve Rowe
Site Admin
Posts: 2083
Joined: Wed May 14, 2008 4:25 pm
OLAP Product: TM1
Version: 10.2.2., PAW
Excel Version: Nearly all of them

DBS should fail, hard!

Post by Steve Rowe » Fri Jul 03, 2020 1:39 pm

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.

User avatar
gtonkin
MVP
Posts: 812
Joined: Thu May 06, 2010 3:03 pm
OLAP Product: TM1
Version: PAL 2.0.3
Excel Version: 2016 64-bit
Location: JHB, South Africa
Contact:

Re: DBS should fail, hard!

Post by gtonkin » Fri Jul 03, 2020 1:59 pm

Sounds like it is borked.

Here's the link if anyone needs it:

+1

Wim Gielis
MVP
Posts: 2529
Joined: Mon Dec 29, 2008 6:26 pm
OLAP Product: TM1
Version: PAL 2.0.8
Excel Version: Office 365 - latest
Location: Brussels, Belgium
Contact:

Re: DBS should fail, hard!

Post by Wim Gielis » Sun Jul 05, 2020 9:58 am

Steve Rowe wrote:
Fri Jul 03, 2020 1:39 pm
I bet I don't get 10 likes!
Currently, you have 8 so 2 remaining.
Best regards,

Wim Gielis

Excel Most Valuable Professional, 2011-2014
https://www.wimgielis.com ==> 112 TM1 articles and a lot of custom code
Newest blog article: Updating process line numbers with AutoHotKey

User avatar
Alan Kirk
Site Admin
Posts: 6191
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2 Classic (PAW-free zone)
Excel Version: 2010 and 2016
Location: Sydney, Australia
Contact:

Re: DBS should fail, hard!

Post by Alan Kirk » Sun Jul 05, 2020 10:47 am

Wim Gielis wrote:
Sun Jul 05, 2020 9:58 am
Steve Rowe wrote:
Fri Jul 03, 2020 1:39 pm
I bet I don't get 10 likes!
Currently, you have 8 so 2 remaining.
I've already cast mine...
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.

User avatar
Alan Kirk
Site Admin
Posts: 6191
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2 Classic (PAW-free zone)
Excel Version: 2010 and 2016
Location: Sydney, Australia
Contact:

Re: DBS should fail, hard!

Post by Alan Kirk » Mon Jul 06, 2020 8:59 am

Alan Kirk wrote:
Sun Jul 05, 2020 10:47 am
Wim Gielis wrote:
Sun Jul 05, 2020 9:58 am
Steve Rowe wrote:
Fri Jul 03, 2020 1:39 pm
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?
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.

Wim Gielis
MVP
Posts: 2529
Joined: Mon Dec 29, 2008 6:26 pm
OLAP Product: TM1
Version: PAL 2.0.8
Excel Version: Office 365 - latest
Location: Brussels, Belgium
Contact:

Re: DBS should fail, hard!

Post by Wim Gielis » Mon Jul 06, 2020 10:21 am

Alan Kirk wrote:
Mon Jul 06, 2020 8:59 am
14 and counting. When does our bet money arrive in our accounts?
When IBM have implemented it 😉
Best regards,

Wim Gielis

Excel Most Valuable Professional, 2011-2014
https://www.wimgielis.com ==> 112 TM1 articles and a lot of custom code
Newest blog article: Updating process line numbers with AutoHotKey

HighKeys
Posts: 97
Joined: Fri Aug 09, 2019 10:11 am
OLAP Product: TM1 / TM1 Web / Perspectives
Version: Planning Analytics V2.0.9
Excel Version: Plus 2013

Re: DBS should fail, hard!

Post by HighKeys » Wed Jul 08, 2020 8:39 am

Wim Gielis wrote:
Mon Jul 06, 2020 10:21 am
Alan Kirk wrote:
Mon Jul 06, 2020 8:59 am
14 and counting. When does our bet money arrive in our accounts?
When IBM have implemented it 😉
So never :lol:

User avatar
Alan Kirk
Site Admin
Posts: 6191
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2 Classic (PAW-free zone)
Excel Version: 2010 and 2016
Location: Sydney, Australia
Contact:

Re: DBS should fail, hard!

Post by Alan Kirk » Thu Sep 17, 2020 11:14 pm

So, here's the response to this one:
IBM wrote: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".
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.

User avatar
Alan Kirk
Site Admin
Posts: 6191
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2 Classic (PAW-free zone)
Excel Version: 2010 and 2016
Location: Sydney, Australia
Contact:

Re: DBS should fail, hard!

Post by Alan Kirk » Fri Sep 18, 2020 1:49 am

Alan Kirk wrote:
Thu Sep 17, 2020 11:14 pm
So, here's the response to this one:
IBM wrote: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:
I wrote: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".
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.

User avatar
gtonkin
MVP
Posts: 812
Joined: Thu May 06, 2010 3:03 pm
OLAP Product: TM1
Version: PAL 2.0.3
Excel Version: 2016 64-bit
Location: JHB, South Africa
Contact:

Re: DBS should fail, hard!

Post by gtonkin » Fri Sep 18, 2020 6:08 am

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.

Post Reply