Hi all,
After upgrading to TM1 version 9.5.2 I observed a strange behaviour of the DBRW function being called from VBA code.
In the previous version 9.0.3 running DBRW from VBA returned either the correct value or KEY_ERROR in case of incorrect element parameters.
Now I get "Error 2042" (which means the same as n/a ?) instead of KEY_ERROR.
Curiously, DBRW formulas in Excel still deliver the known KEY_ERROR.
Any ideas if this is a bug of the mentioned version or just a customizable setting of the server?
I don't assume this is an Excel issue, since it has not been changed (still 2003).
Many thanks for your replys.
DBRW - Error 2042 instead of KEY_ERROR
-
- Community Contributor
- Posts: 110
- Joined: Thu Aug 26, 2010 7:41 am
- OLAP Product: TM1, PA
- Version: PAL 2.0.8
- Excel Version: 2016
- Location: North West England
Re: DBRW - Error 2042 instead of KEY_ERROR
Andy,
We have had the same issue when we upgraded from 9.0.2 to 9.5.2.
Personally I do not see it as a Bug, and to my knowledge is not a server side setting. What we have done in our VBA when doing any DBR's is to wrap the statment in a custom function which will handle any errors.
i.e. ErrorTrapN(DBR(the dbr statement))
The ErrorTrap function can then deal with any unexpected data. Bit of a pain when debugging any code, but better user experience if you are catching errors.
We have had the same issue when we upgraded from 9.0.2 to 9.5.2.
Personally I do not see it as a Bug, and to my knowledge is not a server side setting. What we have done in our VBA when doing any DBR's is to wrap the statment in a custom function which will handle any errors.
i.e. ErrorTrapN(DBR(the dbr statement))
The ErrorTrap function can then deal with any unexpected data. Bit of a pain when debugging any code, but better user experience if you are catching errors.
Always Open to Opportunities
Re: DBRW - Error 2042 instead of KEY_ERROR
Hi,
Thanks a lot for your reply and your suggestion to catch any error that way.
Now I'm relieved that this behaviour of TM1 is normal and not a configuration error.
Adjusting our codes won't be a problem.
Kind regards
Andy
Thanks a lot for your reply and your suggestion to catch any error that way.
Now I'm relieved that this behaviour of TM1 is normal and not a configuration error.
Adjusting our codes won't be a problem.
Kind regards
Andy