Archive for November, 2011
Transitioning a cube from a Windows environment to a Unix environment can be tricky. Your cube may build perfectly in a local-build on Windows, only to give you errors like this in a server-build on Unix:
Start processing data source ‘My Data Source’.
Reading source data.
(TR3703) The user ID or password is either missing or invalid. Please re-enter the credentials.
End processing 0 records from data source ‘My Data Source’.
While it appears as though you have a problem with a data source in Unix, the real problem lies with your signon credentials. Once you transition from a local-build to a server-build in Transformer, you need to have a valid Signon defined. But when you do this, there is no way to test to see if your Signon Credentials will work – short of moving your Transformer model to the Unix server and building it. If your signon credentials are invalid, you will get a message like the one above.
So check the Signon Credentials and that should solve your problem. The apparent reference to your data source is a red herring.
If you ever get the following error when attempting to connect Cognos Framework Manager with an Oracle data source, you have an Oracle configuration problem:
QE-DEF-0285 The logon failed.
QE-DEF-0325 The logon failed for the following reason:
RQP-DEF-0068 Unable to connect to at least one database during a multi-database attach to 1 database(s) in:
UDA-SQL-0432 Unable to locate the gateway “cogudaor”
If you have a valid Oracle client installed on your machine (Oracle 9 or up for Cognos 8/10), then check your System Environment variables. I had a recent experience at a client where both Oracle 8 and Oracle 10 client software were installed on a machine. Because the ora805\bin reference appeared before the ora10\bin reference in the Path variable, Cognos Framework Manager could not connect to the data source and reported the above error. Simply by changing the order of those references in the Path variable, the configuration problem was resolved.
While implementing the Cognos 10 Audit package on an Oracle 10g system, I ran into a problem with one of the pre-defined reports. This one report would fail each time, reporting an Oracle error: ORA-12704 character set mismatch.
My first Google search indicated that there was a problem with Cognos 8.3 Audit package on Oracle 10g. A modification was required in the Framework Manager model, changing all references from nVarChar to characterLength16. Although I was running Cognos 10, I decided to try this fix out. It did not adversely affect my Audit package, but it did not resolve the issue either. As all the model query subjects were working as expected in the original Framework Manager model, I reverted back to it and decided to focus my efforts on the Report Studio report.
Eventaully I isolated the problem down to three If/Then/Else statements in the report, and then realized it was not able to compare query results against an empty string. I casted this empty string into a nvarchar and the problem was resolved:
IF [Audit].[Audit Report Table].[Audit Report Column] = ” THEN…
IF [Audit].[Audit Report Table].[Audit Report Column] = cast(”, nvarchar(1)) THEN…
In the Cognos 8/10 security environment, there are a number of pre-defined Cognos roles that under-pin the entire Cognos security infrastructure. Technically, you can move, rename or delete these roles but do so at your own peril! Cognos recommends not changing these security elements and I’ve had a recent experience that highlights exactly why.
A client of mine, in an attempt to clean up and manage their security environment, moved all of the predefined roles into another directory. On the face of it, this seemingly innocuous act appeared to be no big deal. But then they also installed Cognos Adaptive Analytics. The new Cognos product install did not see the predefined roles, and appeared to have recreated all of them in their original location. This of course caused duplication of all the predefined Cognos roles. The security environment became very confusing as it was very difficult to distinguish between the identically named roles.
Attempting to clean up the duplicates caused untold havoc with users rights and privileges. Some of the old Cognos roles defined certain rights and some of the new ones defined others. Deleting the copied Cognos roles removed most rights under the Capabilities tab and Public Folder rights. All told, a lot of clean up and reconfiguration was required.
So if you get the notion to change your pre-defined Cognos roles, take Cognos’ advice and just don’t do it!