10.1.1 - Is it me, or is it a piece of crap?

[david.stachon]

I regret going from 10.1 which was great, to 10.1.1 which seems to need serious insecticide.

> matrix chart x axis don't sort properly,
> drill through is sketchy (sometimes work, often the endless hour glass, or cryptic error messages)
> frozen "loading" messages in meta-data panel
> the statistics plugin doesn't work at all (apparently, it needs to be installed in a path with no spaces (i.e. even though it defaults to "Program Files\<etc>"
> the ipad app crashes and freezes constantly
> graphs will mysteriously disappear when used in portlets >

How could my upgrade from 8.4 to 10.1 be problem free, and 10.1 to 10.1.1 be such a bloody nightmare!!!!

(sorry, just venting. ....but seriously, don't even consider upgrading to this build. Wait for SP1 at a bare minimum)

[AussiePete2011]

Hi David,
This is a concern as we plan to migrate to this version from 8.4 in the very near future.
Be interested if you've opened a call with IBM on this. If so what was the response?
Cheers
Peter

[shof2k]

Thanks for the heads up.  I wanted to push 10.1.1 as it has a fix for a Data manager bug I've encountered.  Please keep us posted on how IBM help you out. 

[Alan.Richmond]

Wait til you try to make 10.1.1 work on 64 bit

You cant use the 64 bit Report Service unless you publish your framework packages with the use Dynamic Query Mode checked
This option becomes available if your package is OLAP or DMR relational

If your datasource is relational and not DMR the option is not available
Meaning you cant report a relational datasource with the 64bit server

A great step forward

[dinos]

Yeah,

We actually were good on C10.1 until we had SDK issues when publishing packages, which was fixed in C10.1.1, but since we went to that version, we have encountered a ton of issues with our reports, that worked fine in C10.1.  Out of the fire pan, into the fire.

[MFGF]

Wait til you try to make 10.1.1 work on 64 bit

You cant use the 64 bit Report Service unless you publish your framework packages with the use Dynamic Query Mode checked
This option becomes available if your package is OLAP or DMR relational

If your datasource is relational and not DMR the option is not available
Meaning you cant report a relational datasource with the 64bit server

A great step forward

The 64 bit report service is only really doing the rendering piece in that particular situation. Most reports will render just fine in no time at all under the 32 bit report service. Just to be clear, if you are running a 64 bit install with DQM enabled and the 32 bit report service, all the query planning and generation is done within the 64 bit DQM - only the final rendering is 32 bit. Most organizations do not have reports which require more than 2Gb memory to render, so will notice no real difference when using the 64 vs 32 bit report service.

Just the ramblings of a senile old muppet :)

MF.

[charism]

Wait til you try to make 10.1.1 work on 64 bit

You cant use the 64 bit Report Service unless you publish your framework packages with the use Dynamic Query Mode checked
This option becomes available if your package is OLAP or DMR relational

If your datasource is relational and not DMR the option is not available
Meaning you cant report a relational datasource with the 64bit server

A great step forward

Actually with 10.1.1, Relational data sources are also supported but it is a subset of what classic query engine supports, if the data source is one of Oracle, DB2, Teradat, Netezza and SQLServer, it is supported through DQM.

[navissar]

A few minor corrections:
Before 10.1, all reports - even on 64 bit installations - were runnig on 32 bit services (The BIBusTKService).
In 10.1, the DQM was introduced, and it is a full 64 bit service for running reports. In 10.1 it only supported 3 types of OLAP (SAP BW, TM1 and MSAS, IIRC). This is in fact quite a difference because the DQM uses security aware caching, so even if - as the muppet mentioned - no report really brings back more than 2 GB of data, the ability to use the extra memory for caching (Of several reports) is getting very close to the idea of in-memory processing and did in fact show tremendous results for several of my customers as well as in experimental conditions.
DQM also changes the way dimensional queries are used, by working out a hybrid query - basically it means getting the dimensions via MDX and then querying those via SQL from the memory where they are cached, which really gives the best of both worlds and also lessens the burden on the cube; also, it takes off some of the edge of writing dimensional reports (Because part of teh query now can be SQL, some SQL methods in some places may be applied without affecting results or performance, but carefully - you need to understand what you are doing!)
With 10.1.1, DQM now supports all major datasources - SQL Server, Oracle and so on - for relational models as well.
With 10.1.1 any relational/dimensional model can be published using DQM. It is absolutely not true that relational models based on supported databases cannot be published using DQM, and I have several customers who already work exactly like that. I've seen great improvement in response times fro relational reports over DQM for several reasons:
1. You get to cache results.
2. Your connection to the datasource can be a 64 bit JDBC driver and you don't have to use the 32 bit native client - that means you can pull out more reports for every DB connection as there's virtually no memory limitation.

In fact, 10.1.1 is the most 64-bit Cognos version out there, as it is the only app where you can use full 64-bit report processing from datasource client to reporting service, on relational and dimensional data.

As for the other bugs/issues raised here, I have to say I found 10.1.1 to fix several issues we've been struggling with in 10.1, and did not encounter any further issues in 10.1.1 that were not already present in 10.1. However, it is just my personal impression from the few installations and upgrades I've performed.

Cheers,
Nimrod