Migrating from Cognos 6 to 7.3

[Netgurutoo]

It seems that Cognos Impromptu 7.3 hs a new Visible property and the default is Visible = false. There does not seem to be a Visible property in 6.0 and it is defaulted to true. When migrating Macros to 7.3 the Visible property needs to be added so that the prompts appear and the reports get created.

If anyone knows of any similar issues with moving to impromptu 7.3 please post them.



Thank You

Netgurutoo

 

[DanJC]

I'm piloting a migration from Cognos 6 to 7.3 and I've found some really bizarre stuff so far.

The way in which Impromptu interprets the Today() function has changed.

I am using it in conjunction with MS SQL Server and instead of using the current system date, Impromptu converts the system date to text e.g. '2005-10-06' and then calls the
CONVERT SQL function instead of just submitting the date parameter.
The problem is that the default date format for the convert function is US date format and not the local regional format.
As a result SQL swaps the month for the day where the day is <= 12 and returns the wrong information.
I'm looking closely at the source of the problem to see if I can fix it and I'll follow up this post if I find anything (but so far I've amended all the xml files I can find to change the short date format and it hasn't worked).

If anyone else has fixed this problem then please get in touch. As far as I can tell, it seems that Impromptu does not like SQL datetimes because we have had numerous problems with it.

Speak to you soon

 

[Dollie]

Problems encountered after the upgrade:

(Using Impromptu 7.3 w/ SQL)

Report Upgrade Tool (report destruction tool?) bombs if one report in a directory fails to upgrade. Tool and Impromptu both must be closed and restarted. Because of the multiple problems, I was forced to go back through each directory and upgrade reports manually (which ended up being easier in the long run). A lot of our reports (30% or so) are failing because of an upgrade to our accounting software that added quite a few new tables and renamed existing tables, but that doesn't explain why others didn't work with the upgrade tool but upgrading manually worked fine.

I have also seen the same thing that DanJC has seen with the dates.

 

[DanJC]

We carried out a thorough investigation with this date issue and it was the silliest of problems.
The error was not generated by Impromptu but by the ODBC connection.

In order to get the date corrected we had to change the default language format of error message from British English to US English in ODBC administrator - this took us nearly half a day to find and there is no way I would expect a user to pick up on this, given the amount of checking we had to do to find it.

I haven't used the report upgrade tool yet, but I'm still piloting so I may have a play around with it at a later date.

 

[DanJC]

Ok, here's a funny for you.

Something I didn't pick up on is the knock on effect of changing date formats in ODBC.
Each date format treats a different day as the start of the week. As a result, one of the sql functions I was using to generate a total by week:

Dateadd(weekday, 1-datepart(weekday, <date>), <date>)

changed the start of the week from Monday to Sunday.

I didn't think this through correctly and I just changed the 1 to 2 to fix the error, this threw Monday into the previous week instead of the week where it should be included and then I remembered what had gone wrong.
If you get this error, then make sure you include the following line in any SQL procedures:

SET DATEFIRST 1

to make sure that the first day of the week is a Monday and not any other day before you run the query.

I just thought I'd pass this on so that no-one else makes this sort of schoolboy error when people are looking at reports based on views/procedures.

(Was this even worth publishing?)