Never used Audit database etc before. Was asked why it did not worked in our new 10.1.1 development environment. :o
So, performed standard actions on my local 10.1.1. installation and it worked first time (after changing logging settings for dispatcher and restarting Cognos )
Must be missing something obvious though the only difference I can think of is that on development the database is elsewhere on another server.
We use SQL server , so I assume JDBC is not required!?
note:
Did same procedure on 8.4.1 test machine, took only 4 minutes to get it working..
entry from cogserver log:
StartService LogService FAILED Log Server Database error <parameters><item name="DB URL"><![CDATA[jdbc:JSQLConnect://BUSO1\\SQL2005/Audit_C10]]></item><item name="DB Error"><![CDATA[Failed Logon:com.jnetdirect.jsql.JSQLException: Failed connection to named instance [\SQL2005] [java.net.SocketTimeoutException: Receive timed out] url:jdbc:JSQLConnect://BUSO1\\SQL2005/Audit_C10]]></item></parameters>
Looks like JDBC adds an additional '\' to the instance name which results in not being able to connect. When I create the audit database on another server instance the tables are populated..
Quite possibly a bug in Version 10_1_1.. (?)
Is it a named instance?
http://www-01.ibm.com/support/docview.wss?uid=swg21514884
Yes, a named instance. The SQL browser is running on the DB server.
From a 8.4.1 Cognos server all works well, but not for a 10.1.1 one
Anything different happen if you go server:port instead of server\instance?
From the following link:
http://publib.boulder.ibm.com/infocenter/cfpm/v10r1m0/index.jsp?topic=%2Fcom.ibm.swg.im.cognos.inst_cr_winux.10.1.0.doc%2Finst_cr_winux_id9999SettheDatabaseConnectionPropertiesf.html
If you use a Microsoft® SQL Server database, type the appropriate values for the Database server with port number or instance name and Database name properties.
For a Microsoft SQL Server database, you can choose to use a port number, such as 1433, or a named instance as the value for the Database server with port number or instance name property.
For the Database server with port number or instance name property, include the instance name if there are multiple instances of Microsoft SQL Server.
To connect to a named instance, you must specify the instance name as a JavaTM Database Connectivity (JDBC) URL property or a data source property. For example, you can type localhost\instance1. If no instance name property is specified, a connection to the default instance is created.
Note that the properties specified for the named instance, along with the user ID and password, and database name, are used to create a JDBC URL. Here is an example:
jdbc:JSQLConnect://localhost\\instance1/user=sa/more properties as required
To connect to a named instance, you must specify the instance name. For example, you can type localhost\instance1. If an instance name is not specified, a connection to the default instance is created.
The db server houses 2 instances, so I need to use a named instance to reach the one I need. Putting the audit database on the other instance (where I can use server:port) does work succesfully.
It looks like the JDBC connection is correctly build like:
jdbc:JSQLConnect://localhost\\instance1
but the double backslash result in an error (cogserver.log) as the instance1 is approached as: '\instance1' instead of 'instance1'
Quote from: blom0344 on 24 Jan 2012 01:39:32 PM
The db server houses 2 instances, so I need to use a named instance to reach the one I need. Putting the audit database on the other instance (where I can use server:port) does work succesfully.
It looks like the JDBC connection is correctly build like:
jdbc:JSQLConnect://localhost\\instance1
but the double backslash result in an error (cogserver.log) as the instance1 is approached as: '\instance1' instead of 'instance1'
Unix shop here. So I can't test to duplicate as I have no Winblows servers. Sounds like a bug though. This is quick for Support to reproduce. Log a case and get them to give you the APAR number once it's logged, if one does not already exist.
What's the port for the instance? (May be wrong, but my understanding is each SQL instance runs on a separate port)
Dynamic ports by default. But you might be on to something.
Maybe force the named instance to a specific port then try connecting again.
There are MS KBs on forcing MS SQL to a specific port.