xdi bug in 10.1?

[Alan Kirk]

Can anyone who is on 10.1 (Windows 7 32 bit) see whether this is the same for them before I report it as a bug?

- When attempting to open an .xdi (having confirmed that the data directory option is pointing to the correct location and that the location is NOT inside the program files directory; it's a sub-folder under C:\TM1), selecting TM1 -> Dimension Worksheets -> Open in Excel 2003 or the equivalent in Excel 2010 will reveal the correct list of .xdis. When the .xdi is selected, however, a dialog advising that C:\Windows\NameOfXdi.xdi cannot be found. (Hardly surprising since it's obviously not IN C:\Windows.)

- If the .xdi is opened through the File menu, any attempt to save it will result in absolutely nothing happening. No request to specify which server to save it into, and of course no actual save of the dimension.

This is not the same as the issue(s) discussed in this thread, and none of the suggestions in there seem to make a difference.

The problem does not appear in 9.5.2 as far as I can see.

[Alan Kirk]

I've raised this as a bug with IBM because it seems to affect both .xdis and .xrus, which is really making my life pleasant at the moment along with the greyed out Trace Calculation bug. (The latter is supposedly fixed in 10.1.1, which is why I'm currently subjecting myself to the pain of an (attempted) multi-gigabyte download. There is no mention of .xrus or .xdis in the 10.1.1 bug fixes list, though. Guess I'll find out when the downloads finish next month.)

I'll pass on some other things that I've found, though:
(a) You're OK during the Excel session in which the rules are / dim is created. You can load and unload the files as many times as you want. It's only once you shut down Excel and restart that it looks for the things in C:\Windows.
(b) I was getting an annoying dialog stating "Cannot access 'CubeName.xru', followed by another one telling me that 'CubeName.xru' already exists and asking whether I wanted to replace it. Selecting Yes saves both the rules and the .xru. IBM support suggested that the problem was a permissions issue (which I don't think it is) but this particular part of it was. As long as both the Default File Location (File -> Options Save tab in Excel 2010) and the data directory have been added to the Trusted Locations list in the Trust Center of the Excel options dialog, you won't get those messages. This may be of use to others. (Edit: Or it may not. That problem is back again as well, though it's not the one that I care about. )

That change, however, still doesn't overcome the problem that the .xru/.xdis won't open through the TM1 -> Developer ribbon group and therefore won't save. The only way to work around that is to open the files conventionally, save them as standard Excel files, blow away the .xrus, and copy the content from your file copies.

(And yes, I've made sure that there are no (remaining) TM1p.ini files on the system other than my one in the roaming folder.)

[Michel Zijlema]

Hi Alan,

I'm facing similar behaviour on TM1 10.1 / Excel 10 at a customer site. Each time I start the Citrix session in which TM1 Perspectives loads my local path has changed (which I suspect is related to the Citrix setup). When I change the local path to point to the directory holding the XDI and then try to open an existing XDI (which are listed in the dialog box...) I get the error message which shows that TM1 is still looking at the previous path. What I do to get around this is to create a new XDI, then close this wthout saving and then try to open an existing XDI again. At that point the path seems to be refreshed as the XDI file is opened (still giving a warning thet .xdi is an unknown and potential unsafe file format).

Michel

[Alan Kirk]

I'm facing similar behaviour on TM1 10.1 / Excel 10 at a customer site. Each time I start the Citrix session in which TM1 Perspectives loads my local path has changed (which I suspect is related to the Citrix setup). When I change the local path to point to the directory holding the XDI and then try to open an existing XDI (which are listed in the dialog box...) I get the error message which shows that TM1 is still looking at the previous path. What I do to get around this is to create a new XDI, then close this wthout saving and then try to open an existing XDI again. At that point the path seems to be refreshed as the XDI file is opened (still giving a warning thet .xdi is an unknown and potential unsafe file format).

Thanks for that Michel, unfortunately that wouldn't work in this case. The problem is that I can't create a new one because the add-in does, at some level, know that the old one is there; it lists the thing in the dialog. So if you select (say) Rule New it will attempt to open the existing .xru, not create a new one. As soon as it does so you get the "doesn't exist in C:\Windows" message. The only way around it is to delete the original .xru from the data directory which allows you to create a new one, into which I copy the original content.

Apropos your own problem, I have a recollection that Martin came across a problem in Citrix involving different interpretations of what the APPDATA folder actually was; I suggested looking at the value that the Eviron("AppData") value that was being returned in VBA and if I recall correctly (and I may not be) it was pointing to a different location to where we were expecting the tm1p.ini file to be.

This was an off-line discussion, not a Forum thread so I can't link to it but Martin may recall it better than I do and whether it may be the same problem that you're having.

[Michel Zijlema]

Thanks for that Michel, unfortunately that wouldn't work in this case. The problem is that I can't create a new one because the add-in does, at some level, know that the old one is there; it lists the thing in the dialog. So if you select (say) Rule New it will attempt to open the existing .xru, not create a new one. As soon as it does so you get the "doesn't exist in C:\Windows" message. The only way around it is to delete the original .xru from the data directory which allows you to create a new one, into which I copy the original content.

Just adding for all certainty: when I create a new dimension worksheet I'm not using an existing name, I just select New Dimension Worksheet, enter a random name like 'abcd' and click OK. This will open up a blank definition sheet, which I just close without any further action. After this the Open Dimension Worksheet function works for me.

Thanks for the remarks on the Citrix setup - I will have a look at this when I'm back with the customer.

Michel

[Alan Kirk]

Thanks for that Michel, unfortunately that wouldn't work in this case. The problem is that I can't create a new one because the add-in does, at some level, know that the old one is there; it lists the thing in the dialog. So if you select (say) Rule New it will attempt to open the existing .xru, not create a new one. As soon as it does so you get the "doesn't exist in C:\Windows" message. The only way around it is to delete the original .xru from the data directory which allows you to create a new one, into which I copy the original content.

Just adding for all certainty: when I create a new dimension worksheet I'm not using an existing name, I just select New Dimension Worksheet, enter a random name like 'abcd' and click OK. This will open up a blank definition sheet, which I just close without any further action. After this the Open Dimension Worksheet function works for me.

Ah, right sorry I see what you're getting at now. My particular issue yesterday was with .xrus rather than .xdis. I did try something similar (creating a new rule on a cube that previously didn't have any), which created the .xru normally for that cube but still didn't fix the problem with the other two cubes' ones.

Thanks again.

[ellissj3]

Was there any resolution via IBM PMR? I am experiencing same issue.

[Alan Kirk]

Was there any resolution via IBM PMR? I am experiencing same issue.

I honestly can't remember what happened with that PMR, and I can't find it in my list of support requests even after adding in the "Archived" option for the search. (However we've been bounced around a bit account-wise with IBM service, so it's entirely possible that it was lodged under the old account.) I sent 10.1 to Valhalla some time ago (and only ever had it as a test environment anyway) so I don't know whether it was ever fixed.