Cognos Feeds
|
Knowledge Articles
|
CogKnowHow.com - The IBM Cognos Knowledge Base | Links Documentation Forum Community Tips and Tricks
|
-
Minimal support for Microsoft Internet Explorer 6 with Cognos 10
Symptom
When you use Microsoft Internet Explorer 6, IBM Cognos Business Insight might function correctly; however, performance is reduced and the appearance is degraded.
Cause
IBM Cognos Business Insight does not fully support Microsoft Internet Explorer 6.
Solution
For intended visual display and performance, use a more recent browser such as Mozilla Firefox version 3.5 or higher, Microsoft Internet Explorer 8, or Microsoft Internet Explorer 9.
Check the Cognos 10 weblinks section for more information
www.cogknowhow.com
-
SQL0101N The statement is too long or too complex
This DB2 Error occurs when attempting to run a large report or during a search of the content store.
CM-SYS-5092 Content Manager failed while returning the query results.
[IBM][CLI Driver][DB2/6000] SQL0101N The statement is too long or too complex. SQLSTATE=54001
This is an known issue with the heap size for DB2. To update the heap size.
Steps:
The following is an extract from DB2 documentation:
SQL0101N The statement is too long or too complex.
Explanation: The statement could not be processed because it exceeds a system limit for either length or complexity, or because too many constraints or triggers are involved. The default statement heap size for DB2 is too small to support the complex SQL statements. Try updating the statement heap size to be 8000 or more. To update the heap size, open a DB2 command prompt and type the following: > db2 update db cfg for <database name> using stmtheap 8000
www.cogknowhow.com
-
Problems Migrating Reports with Internal Path Names Exceeding 255 Characters
Symptom
S7S-ERR-0813 Exception encountered parsing IBM Cognos Deployment Manager errors and warning from file: UNEXPECTED INTERNAL ERROR: CDM dump is missing the "PPES.packletLocation" property. Problem
When migrating Upfront content, if the number of characters used for the folder name and report name exceeds 255 characters, the migration fails.PowerPlay Enterprise Server may also generate a core file in the S7_install/bin/ directory. Cause
When path names exceed 255 bytes in length, the IBM Cognos Series 7 PowerPlay Enterprise Server process may overflow a buffer. In particular, you may want to check the length of your paths in the PPSRoot directory. For example, S7_install/ppserver/PPSRoot/... Solution
You are most likely to encounter this problem on UNIX
UNIX usually permits path names of 1023 or more bytes. Windows limits path names to 260 bytes when using the APIs that PPES uses. When using a multi-byte language such as Japanese. A single character can occupy two or more bytes. Consequently, path names can reach the 255 byte limit with fewer characters. To work around the problem, contact the IBM Cognos Support for a software update to address bug 603523.
Or
you can avoid the problem by selecting to migrate only NewsBoxes containing reports with path names that are less than 255 characters in length. Or rename the report and NewsBox names so that they use less than 255 bytes.
-
DPR-DPR-1035 Dispatcher detected an error
When Installing Cognos BI 8.2 or 8.3 you will encounter the following message during startup [Archive Local File System Root]
1. Since the value is empty, the feature is disabled. There is nothing to test.
[Start Service]
1. 13:35:14, 'LogService', 'StartService', 'SUCCESS'.
2. 13:35:14, 'LogService', 'StartService', 'Success'.
3. 13:35:22, 'AuditDatabaseConnection', 'Execute', 'Success'.
4. 13:35:21, CM-SYS-5159 Content Manager is running in active mode.
5. 13:35:21, 'ContentManagerService', 'StartService', 'Success'.
6. 13:35:22, DPR-DPR-1002 Successfully registered the dispatcher http://localhost:9300/p2pd in Content Manager.
7. 13:35:23, 'com.cognos.pogo.monitoring.jmx.PogoMBeanServer', 'pogo', 'Failure'.
DPR-DPR-1035 Dispatcher detected an error.
com.cognos:type=queue,service=dataMovementService
8. 13:35:27, 'ReportDataService', 'StartService', 'Success'.
9. 13:35:27, 'PresentationService', 'StartService', 'Success'.
10. 13:35:27, 'DataMovementService', 'StartService', 'Success'.
11. 13:35:27, 'ReportService', 'StartService', 'Success'.
12. 13:35:27, 'BatchReportService', 'StartService', 'Success'.
13. 13:35:27, 'AgentService', 'StartService', 'Success'.
14. 13:35:27, 'SystemService', 'StartService', 'Success'.
15. 13:35:28, 'MonitorService', 'StartService', 'Success'.
16. 13:35:28, 'DeliveryService', 'StartService', 'Success'.
17. 13:35:27, 'EventService', 'StartService', 'Success'.
18. 13:35:27, 'JobService', 'StartService', 'Success'.
19. 13:35:28, 'CPS Producer Registration Service', 'StartService', 'Success'. This is a known issue and can be ignored because if you look in the administration console in Cognos connection you will see that the datamovement service is up and running. There is no fix in 8.3. In Cognos 8.4 this product issue is fixed.
-
Deployments fails after Planning Store tables are upgraded to 8.4
From the planningerrorlog.csv for the service account:
Unable to assign 196 character BLOB value to field cm..P_PNREQUEST.request.~~~~Multiple-step operation generated errors. Check each status value.
Multiple-step operation generated errors. Check each status value., Error number -2147217887 was raised by Microsoft Cursor Engine
Cause
The request field in the P_PNREQUEST table did not get updated to the appropriate data type.
Solution
Create a new Planning Store or Content Store if a separate Planning Store was not used.
or Use a a SQL script to correct the table. /**** Cleanup table P_PNREQUESTPROGRESS ****/ TRUNCATE TABLE [dbo].[P_PNREQUESTPROGRESS]; /**** Drop table P_PNREQUEST ****/ DROP TABLE [dbo].[P_PNREQUEST]; /**** Create Table [dbo].[P_PNREQUEST]****/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO SET ANSI_PADDING ON GO CREATE TABLE [dbo].[P_PNREQUEST]( [requestguid] [char](38) NOT NULL, [requestname] [varchar](500) NOT NULL, [requesttype] [varchar](500) NOT NULL, [runstateid] [varchar](250) NOT NULL, [startdt] [char](29) NULL, [lastcompletiondt] [char](29) NULL, [failurenote] [text] NULL, [executioncommand] [varchar](250) NULL, [request] [image] NULL, CONSTRAINT [pk_0jn85] PRIMARY KEY CLUSTERED ( [requestguid] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY] GO SET ANSI_PADDING OFF
www.cogknowhow.com
-
Default sender remains default@noticecast.com
Problem:
all messages for notification come from - default@noticecast.com
Workaround:
Go to your Cognos-Folder cognos\c8\configuration and open the cogstartup.xml
Locate section
<!-- DefaultSender: Specifies the email address of the sender. -->
<!-- This setting specifies the email address of the 'sender' of outgoing messages. Use
a valid email address. -->
<crn:parameter name="DefaultSender">
<crn:value xsi:type="xsd:string">notifications@cognos.com</crn:value>
</crn:parameter>
Change
<crn:parameter name="DefaultSender">
to
<crn:parameter name="defaultSender">
and enter your choice of Sender in
<crn:value xsi:type="xsd:string">yoursender@yourcompany.com</crn:value>
Now your emails are sent from this adress.
NOTE:
Every time you press the SAVE button in your Cognos Configuration, This parameter is automatically changed back to the original one...
There is a hot fix for this now, defect 613813
|
|
|
|
