We are upgrading from Excel 2003 and Perspectives 8.4.5 running with a 9.0 server to Excel 2007 and 9.5.2 . Ran into a problem with a dimension worksheet that includes the following elements (Note the comma in the name):
Anderson, Donna
Anderson, Richard
1. When we try to edit the dimension worksheet in Excel 2007 using Dimension Open we first get the following message: "The file you are trying to open, 'TCNames.xdi', is in a different format than specified by the file extension. Verify that the file is not corrupted and is from a trusted source before opening the file. Do you want to open the file now?" We can open the file and edit it - no problem.
2. However when we go to Dimension Save we get the following error Duplicate element <"Anderson>.
Item 1 is an inconvience that I would also like to eliminate. Any ideas?
The biggest problem is not being able to save the dimension . Are there any fixes for this?
Why not prefix it or just use employee id? You can always use an alais for the persons name. I've never liked using people's names as sometimes as most organisations have duplicates such as Wayne Kerr.
Have you tried taking out the space after the comma?.
We're also upgrading to 9.5.2 and have encountered the same problem. Particularly in our chart of accounts, with consolidation level elements such as "Property, Plant and Equipment". When saved using a dimension worksheet, the element appears in the dimension as:
"Property
ie it adds double quotes at the start of the element and then truncates everything after the comma. If there are elements which are the same up to the point of the comma (as in your case with the two Andersons), the truncation results in duplicate name errors being thrown up.
The workaround we have used is to use a TI to find all elements in all dimensions which contain commas, remove all commas from the elements found, then created an alias to hold a display name which has the commas included. An unfortunate side effect of this however is that a number of our MDX based subsets failed as the primary name for elements involved in the MDX had changed (so a word of caution if you're heavily reliant on dynamic subsets).
Interestingly, if you create a dimension worksheet, then edit the dimension through the server explorer interface, you can insert elements with commas in their names. When you hit save and you're prompted if you want to update the dimension worksheet, click on yes. Open the worksheet, and the elements will be there, complete with commas. If you then save the dimension worksheet and go back to the dimension through the server explorer, you'll see the double quotes and truncated version. So another workaround may be to switch to only using the TM1 dimension editor - doesn't hold much appeal for me personally, but each to their own.
I've tried the 9.1 and 9.5.2 clients pointing at a 9.5.2 server, and get the same behaviour in Excel 2003, 2007, and 2010, so it looks like a special new "feature" of the 9.5.2 server.
As for your other point on "The file is in a different format blah blah blah" - we're getting that with Excel 2007 and 2010, but as per your experience it doesn't appear to cause any problems other than being annoying.
Does preceding the element with a single quote help? If not, the other option is to maintain the list in a text file and use TI to import it. Worth raising a bug though.
Bob Stuecheli wrote:The file you are trying to open, 'TCNames.xdi', is in a different format than specified by the file extension. Verify that the file is not corrupted and is from a trusted source before opening the file. Do you want to open the file now?
You can fix this one reasonably easily. Just google it and you'll find steps to update the relevant registry setting. It's nothing to do with TM1, it's Excel being over zealous.
Martin
Please do not send technical questions via private message or email. Post them in the forum where you'll probably get a faster reply, and everyone can benefit from the answers. Jodi Ryan Family Lawyer
stex2727 wrote:Why not prefix it or just use employee id? You can always use an alais for the persons name. I've never liked using people's names as sometimes as most organisations have duplicates such as Wayne Kerr.
Have you tried taking out the space after the comma?.
Steve
A common problem. Many Wayne Kerrs in my organization too.
claytonmcguire wrote:We're also upgrading to 9.5.2 and have encountered the same problem. Particularly in our chart of accounts, with consolidation level elements such as "Property, Plant and Equipment". When saved using a dimension worksheet, the element appears in the dimension as:
"Property
....
The bug asside (which seems clearly to be a bug). Why on earth would you set a CoA description as the principüal element name when you have a perfectly good primary key in the account code itself? This strikes me as a blatently absurd design as it exposes the model to all sorts of maintenance issues should account descriptions change (as they are bound to over time.)
I have had the same issue in 9.5.2. - logged issue with IBM last week - IBm was able to duplicate issue
and reported back to me that this is a 9.5.2 bug - as of this time they have not give me a workaround.
Thanks for all the replies. Unfortunately, removing the comma is not an option for us for reasons that I will not try to explain here.
Clayton, our workaround (a 4 letter word in my vocabulary) also is to use the Dimension Editor in Server Explorer which seems to work. However we use Dimension worksheets for all our dimensions that are manually maintained so this will be the one exception. We don't really like the Dimension Editor either.
Martin, preceding with a single quote did not work. Thanks for the google hint - I will look into that.
Lewis, I will log the issue with IBM as well. Maybe if enough people log the issue IBM will address it (am I a hopeless optimist?).
Totally agree, and at the leaf level everything is done by account code. We have descriptions at the consolidation level though and these are the bits that gave us grief. Ideally I'd like to have codes at all levels and have aliases/text attributes for the descriptions, but the system was fairly well established when I inherited it and resource constraints make it something I won't be addressing any time in the near future. Thankfully it's not too much of a maintenance nightmare as while account names change fairly regularly, the roll ups don't (eg Total Income, Net Assets).
A bigger problem for me is when users slice with the description alias turned on and make it into a report, put in a change request two months later to change the account description, and then blame my team for breaking their reports...
What language is selected in your Windows Regional and Culture Settings ?
English ?
(Windows Control Panel -> Windows Regional and Culture Settings -> Tab: "Regional Settings" -> List Box: "Language")
What happens if you change your language from "English" to a non-english language like "German" before starting TM1 9.5.2 Perspectives ?
Can you successfully process your dimension worksheet using commas in dimension element names when you are using "German" as your language in your Windows Regional and Culture Settings ?
English was selected - I switched to German and I was able to save dimension. I switched back to English
and changed the list separator from , to ; and that also worked .
I have ticket in with IBM - a 9.5.2 client fix is suppose to be in an October release - I will pass this on .
* IBMs interim suggestion was to point a 9.5.1 client to the 9.5.2 server to manage dimension update - have not done
this yet - would like the 9.5.1 client on the 9.5.2 server for update performance - but concerned about corrupting my pre-prod
environment (??)
Thanks for your help - this is really been a pain to work around .
. Ran into a problem with a dimension worksheet that includes the following elements (Note the comma in the name):
. Are there any fixes for this?
