T1) Write Access Denied - excel error when writing over cell

[shockwave]

Hi All,

A couple of our users have encountered a strange issue where when data is sliced into excel and user tries to overwrite that tm1 forumulae referenced cell with a hard coded number it returns the following error:
" T1) Write Access Denied "

Has anyone encounted this error b4?? Or have an explanation of what this might mean????

Cheers

Shock

[Alan Kirk]

A couple of our users have encountered a strange issue where when data is sliced into excel and user tries to overwrite that tm1 forumulae referenced cell with a hard coded number it returns the following error:
" T1) Write Access Denied "

Has anyone encounted this error b4?? Or have an explanation of what this might mean????

(a) You're writing (or trying to) to a consolidation; or
(b) to an element that you only have read permission on or
(c) to a rule-based element.

[shockwave]

Hi Alan,

a) not writing send back data into the cube but tring to overwrite a single cell ( with a DBRW formulae) with a hardcoded number in an excel spreadsheet
b) the elements have read permission but all the user is doing is overwritting the formulae
c) the elements that are being overridden are not rule based

The user now has to input an "=" sign and then the value when overwritting the cell in excel. Note user is not trying to send back data but
merely manipulate the output from tm1. This only appears to be a new issue and the user has always had the ability to do this.

Just had a look at the forumlae and i didn't relise that you could send using this formulae instead we use a DBS. When slicing data from tm1 is it possible to "turn off" the write back ( it seems that this was turned off????? and now has been turned on??? ) . It appears the user was always able to do this, are they pulling my leg??


Cheers

Shock

[Alan Kirk]

Hi Alan,

a) not writing send back data into the cube but tring to overwrite a single cell ( with a DBRW formulae) with a hardcoded number in an excel spreadsheet
b) the elements have read permission but all the user is doing is overwritting the formulae
c) the elements that are being overridden are not rule based

The user now has to input an "=" sign and then the value when overwritting the cell in excel. Note user is not trying to send back data but
merely manipulate the output from tm1. This only appears to be a new issue and the user has always had the ability to do this.

Just had a look at the forumlae and i didn't relise that you could send using this formulae instead we use a DBS. When slicing data from tm1 is it possible to "turn off" the write back ( it seems that this was turned off????? and now has been turned on??? ) . It appears the user was always able to do this, are they pulling my leg??

I have to ask this, but... Are you extracting the Michael by any chance?

The functioning of DBRW formulas is TM1 101. More specifically, the 9.1 User Guide, page 616.

[shockwave]

Thanks Alan. I wish I was taking the u know what, maybe I should RTFM. Something I obviously overlooked.

Thanks again

Shock

[Alan Kirk]

Thanks Alan. I wish I was taking the u know what, maybe I should RTFM. Something I obviously overlooked.

Wasn't sure whether you were or not because the write-back is a big selling point of TM1. There's no way to disable the feature in DBR / DBRW formulas short of:
(a) Pointing to a consolidation;
(b) element Security; or perhaps easiest of all
(c) Using worksheet protection to lock the cells. Obviously this isn't an option if you want the users to be able to replace the numbers with hard coding though. That having been said, if the report is protected without a password (which obviously doesn't secure it, but does prevent accidental changes), then ZapFormulas in TM1 Tools will still convert the formulas to static values by flipping the protection off and then re-applying it.

[Kyro]

I think I get whats happening, is the user trying to remove the formula but can't due to TM1 thinking the user is trying to enter information?

[shockwave]

Yep Ben thats right. Working in the back end most of the time this is the first time in 3yrs someone has flagged it. Just seemed unusal at the time but make perfect sense. How is the new tool going??

[Kyro]

I've only seen this since 9.1, to get around it I think you can do a few things.

try these:
+Disconnect from TM1 then try.
+Select a bunch of cells around (including) the dbrw's and try the hotkeys: alt,e,c,a (alt - edit - clear - all).
+Copy and do a paste special/Values.

Hope that helps,

In-Memory olap server is coming along ok, I've given it to a few sydney TM1 consultants to pull apart and offer feedback before a release 1. Drop me a line if you want to beta test

[Alan Kirk]

I've only seen this since 9.1, to get around it I think you can do a few things.

I can pretty much guarantee that the described symptoms, specifically a value being sent up to the server (or in this case, attempting to be sent, and failing) when:

tring to overwrite a single cell ( with a DBRW formulae) with a hardcoded number in an excel spreadsheet

will occur in versions well before 9.1.

[Steve Rowe]

I think they are trying to remove the DBRW formula and then enter a value into the cell but can't because the TM1 client is stopping them. If it's new functionality it should be a good thing as one of the problems with the DBRW is the ease with which it could be replaced by a value and the difficulty that exists in spotting that not all the numbers are being pulled from the server.

Sill I guess they can't keep everyone happy!
Cheers

[Kyro]

Yes Alan, we all know TM1 sends data entered onto DBRW's to TM1 and has for a long time.

The issue here is when you are trying to remove/delete the DBRW's and TM1 puts the DBRW formula's back and gives the error "T1) Write Access Denied...".

Steve, theres a good trick to finding where DBRW's have changed to static values. Press "Ctrl key and tilde key" and all the cells will show their formula. Hit it again to hide all.

[Alan Kirk]

Yes Alan, we all know TM1 sends data entered onto DBRW's to TM1 and has for a long time.

The issue here is when you are trying to remove/delete the DBRW's and TM1 puts the DBRW formula's back and gives the error "T1) Write Access Denied...".

No Ben, the issue here, if you re-read the initial post, is that the user was trying to "remove/delete" it by punching a constant value into the cell. That does not "remove/delete" it, never has and never will. You can preface the entry with an equals sign to tell Excel that you're overriding the existing formula with a new one, but that's not a constant value. But trying to overwrite it with a constant value is not going to delete a DBRW formula the way it will a standard Excel formula. Had they been pressing the Delete key and getting the error, it may have been different but the posts seemed both consistent and unambiguous about what was happening:

user tries to overwrite that tm1 forumulae referenced cell with a hard coded number

tring to overwrite a single cell ( with a DBRW formulae) with a hardcoded number in an excel spreadsheet

IMHO a statement that this is some kind of behaviour which is version-dependent had the potential to be confusing to a user with limited experience, which is why I didn't just let it slide.

[Kyro]

I think I get whats happening, is the user trying to remove the formula but can't due to TM1 thinking the user is trying to enter information?

Yep Ben thats right.

[Alan Kirk]

I think I get whats happening, is the user trying to remove the formula but can't due to TM1 thinking the user is trying to enter information?

Yep Ben thats right.

And the reason that TM1 was "thinking that the user is trying to enter information" is... that they were. Because the way that they were "trying to remove the formula" was... by punching a constant value into it or, as they thought, over it. This was stated clearly, twice. It really didn't need to be complicated beyond that. I reiterate. This is not something new in 9.1, this is the same behaviour that will be found in every version, from the very start of the product.