Error after upgrading to FP1

[Roger_Lewin]

Hello everyone!

I got a strange error after upgrading to FP1. When doubleclicking an Excelcell containing a SUBNM Formula, a messagebox informes me, that the macro "EvaluateArg" cannot be found.

Has anyone stumbled over this and found a solution?

Regards,
Roger

[kangkc]

Supply all parameters.

eg;

=SUBNM("server:dimension',"","")

It used to work with just the 1st parameter but seems like FP1 has changed that.

[Roger_Lewin]

I already supply all parameters, including the optional Alias-Name. Can't be the reason.

[George Regateiro]

We revceived this error pre FP1 on 9.4. Right now it has fallen to the bottom of the list since in another glorious instance of SUBNM fun since all affected sheets work perfectly in TM1Web which is all we use. But since it was a new feature I wanted to explore it. I should hopefully be able to look at it later today or tomorrow since the rest of the testing is winding down. Sorry I could not be of more help at the moment.

[paulsimon]

Roger

I was wondering if you are using 9.1.4 or 9.4.1 (as far as I am aware Cognos have only release 9.4 MR1).

We are being offered a FP1 for 9.1.4. Is that the same as your version?

Regards


Paul Simon

[George Regateiro]

After thinking about the upgrade process a little bit I remembered that we also had some issues with the SSL certificate and the wrong add in trying to load every time (to fix this I had to edit the INI file directly), so I decided to unistall and reinstall perspectives from scratch and I can now get to the subset editor without any issues.

If you could take a little bit and try reinstalling the client to see if it will clear up the issue. It appears that their transition to the new IBM Cognos directory structure did not go over smoothly in all cases.

[lotsaram]

Paul - 9.4 FP1 is available from IBM Fix Central

kangkc - I haven't had a chance to test this yet on 9.4 FP1 (9.4 MR1 works fine). But if it is the case as you say that double-clicking a formula that only has the first argument i.e. SUBNM("server:dimension") now throws this error then I would most definitely see this as a regression bug. This has always been quite useful functionality, in fact I always teach it in end user courses as it makes users more comfortable that they can easily "cheat" to write a SUBNM formula, just add the server:dim argument, double-click and subset editor writes the rest of the formula for you. While this would by no means be a serious regression bug it is still something that should be fixed.

[kangkc]

Yep. The problem is on 9.4MR1 FP1. I don't remember seeing the same behavior in 9.1.4.

The error in our case ends up with a type mismatch and the whole excel has to be closed and re-opened.

There are other MR1/FP1 issues like the edit formula (worksheets reference) etc....well. 9.1.4 is much more stable from client interface perspective.

[Roger_Lewin]

Hello again,

the solution was quite simple. The installation obviously did not replace the xla. I got it from a kind person from IBM, replaced it myself - et voila - it worked.

It's Version 9.41 FP, yes, not 9.1.4

Roger

[Alan Kirk]

I had a tap on the shoulder about this one this morning with regard to something which hasn't been widely noticed about 9.4.1 FP1.

Unfortunately, it looks like Iboglix broke the functionality discussed in this thread when they were enhancing another part of SubNM's functionality.

Specifically, if you look at the 9.4.1 FP1 release notes, you'll see

TM-6292
If a TM1 SUBNM function uses formulas or cell references in any of its parameters, the value evaluates properly, but when double-clicked it will not open the subset editor.

As we all know, this has traditionally been the case. If you have the name of the server in (say) cell A1 so that you can change the server name in a single location, you can't use

Code: Select all

=SUBNM(A1 & "Scenario","","Final")

because if you do so and double click on the cell, all that will happen is that the cursor will go to cell A1.

In FP1, however, if you use that syntax then the subset editor will launch. Yahoo, and huge improvement.

However...

In making the change it appears that the "works with just the first parameter" syntax got broked.

I thought that I had the latest version of 9.4 on my notebook, but imagine my surprise when I noticed "Hey, wait a minute... it's 9.4.0". Oooh-kay.

I tested the "first parameter only" syntax in 9.4.0. Worked fine (except for something that I'll note later). Tested the =SUBNM(A1... syntax. Didn't work, as expected.

I then upgraded to 9.4.1.

The "first parameter only" syntax worked fine. The =SUBNM(A1... syntax didn't.

I then upgraded to 9.4.1 FP1.

The "first parameter only" syntax not only didn't work any more, it ALSO generated an unhandled error code 13 (Type Mismatch) which only gave me the option of selecting [End] to stop the VBA code from running. This had another unfortunate side effect; because it was an unhandled error, double clicking on VALID SubNm formulas didn't work either. However recalculating the sheet apparently reinitialises any (presumably object) variables that need to be. After that was done, the "all argument" subnm's worked normally again.

The =SUBNM(A1... syntax DID work, meaning that at last we (or at least those on 9.4.1 FP1 or higher) can design a single report and have it point to different servers (eg, moving from a dev to a production server) by changing only a single cell. Woo and hoo, very cool, nicely done.

But I'm afraid that they need to at the very least fix the unhandled error (since as anyone who's read my posts previously knows, I view unhandled VBA errors AS THE WORK OF THE DEVIL!!! ), and ideally put back the functionality where you can create a SubNm with a single argument (since that's really cool functionality to have).

Now I DID notice one other thing that I'd regard as a glitch, though the rest of you probably don't even think about it since many of you are several versions ahead of me.

In 8.2.12 (our non-Web production version), if you double click on a SubNm formula and select a new element, you STAY on that cell. This is fair enough.

What I found in 9.4 (all versions) is that if you do that, you move a cell to the right. I also found that that's the behaviour in 9.1 (which is used for our Web server), which means that this change came in somewhere between 8.2.12 and 9.1.

Also, this movement to the right occurs regardless of your "Move On Enter" option in Excel.

This makes less sense than the 8.2.12 design, IMHO.

The problem is that title elements are usually stacked VERTICALLY. It would make sense for the cursor to move DOWN after you've selected a SubNm since the next cell that you'll want to select is probably the one below the one that you're on.

It would make even more sense if the movement (if any) complied with your Excel option selection. In the absence of that, staying on the same cell makes sense. But moving one cell to the right? I don't get the virtue of that.

I'd put in a bug report on these issues, but with Cognos Insight closing down this weekend and me yet to have mastered navigating the IBM site (which I suspect could have been used for one of those labrynth role playing games from the '80's), I can't do that yet.

(I really need to see whether Tom Tom offers some software for my GPS to help me navigate that site. On the other hand I'm not sure that Mr T (who provides my navigation voice - c'mon, who did you THINK I'd have, the Dali Lama?) would be up for that. "Whazzis fool site askin' you to log in for, it's got your name at the top, why would it be showin' your name if you weren't already logged in, this site's just givin' us jibber-jabber, don't MAKE me jump outa this machine IBM, 'cos ah WILL, fool!!!".)

[Steve Vincent]

Don't worry, the nurse will be along real soon

I can confirm it also jumps to the right in 9.0 SP2. My guess its a switch from 8 to 9 that changed it. I can shed some light on maybe why they did it tho. The cube editor has always peeved me off by not sticking to the normal state that Excel installs with by moving RIGHT on the enter key rather than DOWN. Some of our data we prefer to be entered direct in the cube, but its really hard work when someone used to Excel's behaviour than has to revert to arrow keys if moving down the page. Maybe they changed the SUBNM behaviour to fit in line with that of the cube browser?

[Alan Kirk]

Don't worry, the nurse will be along real soon

I can confirm it also jumps to the right in 9.0 SP2. My guess its a switch from 8 to 9 that changed it. I can shed some light on maybe why they did it tho. The cube editor has always peeved me off by not sticking to the normal state that Excel installs with by moving RIGHT on the enter key rather than DOWN. Some of our data we prefer to be entered direct in the cube, but its really hard work when someone used to Excel's behaviour than has to revert to arrow keys if moving down the page. Maybe they changed the SUBNM behaviour to fit in line with that of the cube browser?

Don't gimmie none o' that jibber jabber about nurses, foo'!Or none o' that jibber jabber about movin' the cursor down in cube viewer either! (And more to the point, DON'T GIVE THEM ANY IDEAS!)

I suppose that that's a possibility, but if so it's the daftest decision that they've made since they moved chore scheduling from local time in V7 to UTC in V8. Sometimes not everything needs to be consistent for the sake of it. In the case of the use of time system, having logs in UTC makes sense (for synchronising), having chores in UTC doesn't. Moving right in cube viewer makes sense since, your users notwithstanding, the majority of users probably have the time dimension across the columns and are entering or spreading horizontally.

Moving right on a SubNM, on the other hand, makes no sense at all.

Actually the way Cube Viewer SHOULD work is the same as Excel; with the option to move in whatever direction you specify. But that would involve having an actual Options dialog instead of (with a handful of exceptions) shoving everything into a Windows 3.1 vintage .ini file.

[Steve Vincent]

Completely agree with you on that, but spare a thought for our Arabic friends that read right to left. I just switched the cube browser in to that mode and the arrow keys get reversed! Round of applause for the muppet that didn't notice that one

[appleglaze28]

I came across this issue before, you should try to reinstall TM1 or copy the "bin" folder from a working installation to your server. I'm not sure what this issue is about but that's the solution.

Hope that helps.

[Jaguar]

Hi Folks,

I too was having issues with SUBNM. When I double click I get the same EvaluateArg error. This was under 9.4 MR1 FP0001.

I have re-installed the previous version 9.4 MR1 and the issue has resolved itself.

*shakes head* @ IBM product release for letting something as significant as this go to market.

[belair22]

Anyone else finding TI's are taking forever to open in 9.4 (most releases).... talking magnitude of minutes under some circumstances with OLAP data sources - just to be clear this isn't executing a TI, merely opening it for editing in Perspectives/Server Explorer.

[paulsimon]

Belair

When you open a TI, TM1 always runs the SQL to check that it can still connect, and then it runs it again when you execute the TI. So if your SQL takes a long time to run, the TI process can take a long time to run.

There are a few cures for this. In the old days of version 7 we used to go on to the SQL box and kill the process. Now in later versions, if you code the SQL so that it needs a TI variable eg ?vYear?, then the SQL will fail every time, and let you get on with editing the TI process much earlier. You just need to provide a value for the variable in the Prolog.

Regards

Paul Simon