user cannot save Contrib web data after running system link

[jeffowentn]

Cognos 8.4.1
Windows 2003
SQL Server 2005
Windows XP
Office 2007

I have some users who cannot save their data after running a system link in Contributor web.  It appears everything is in order.

What should I be looking for?

[ericlfg]

Hey Jeff,

Nothing in the logs or GUI error messages encountered?  What's the exact process that the end user follows and at what point does something appear to be 'off' ?

Cheers

[jeffowentn]

Nothing that I can see in the logs (on the planning server or on the user's machine)...

User opens Contrib - runs system link...numbers change (blue)...goes to save the data in the web, and this very imformative error appears:

The following error was reported by the server :-

Unknown error


That's all that I have to work with.  Same result in both our DEV and PROD instances.

Jeff

[ericlfg]

Just quickly without digging back through my notes..  what DB provider are you using?  Also, based on the number of changes a change in the metabase.xml file may need to be modified (resource increase) as the save may be trying to save more than the resource value that's currently specified..

[jeffowentn]

Using SLQ 2005...

Also, I tried running the system link and saving the data in Contributor and also had a problem.  Either it is a permissions issue in the portal (which I am less familiar with, coming from 7.3 world) or there is some other configuration that is keep both of us from doing this in both DEV and PROD.

[ericlfg]

Jeff,

What driver are you using for this application?  SQLOLEDB or SQLNCLI?  There's a few TN's that I've seen regarding a couple of these error messages.. 

This is one I would start with: https://www-304.ibm.com/support/docview.wss?uid=swg21346695

Edit: You may already have the NCLI driver installed, confirm from the ODBC management screen under the Driver tab..  it'll be at the bottom and look at the path.  Open the CAC and select the application in question, you should see the connection string and the driver being used.

Cheers

[jeffowentn]

In the process of getting the changes applied you suggested, earlier, Eric.

In the meantime, I'm now getting an error that says "Unable to retrieve system link source" when trying to run a system link.  I suspect this may be a hardware/performance issue, though, so we are experiencing issues that point to only having a single EP App server/dispatcher to handle everything (not intended, but the remaining hardware hasn't been provisioned and configured, yet).

Thoughts?

[jeffowentn]

Eric - the TN you suggested references re-configuring the PAD, but that does not work in 8.4 as described.  Where do I go for 8.4.1?

[jeffowentn]

Eric - no PAD in 8.4.1 - configured the datastore to use SQLNCLI and that also applied to all 108 applications in the environment...DBA also made the appropriate changes to the pertinent application databases that we were trying to test for this issue...no opportunity to modify the configurations for the PAD and the URL given for the web changes in steps 22-25 are not applicable to 8.4.1.  I opened a node in a Contributor application (one of the two affected db's mentioned above) via Cognos Connection with no problems.

The user still cannot save data in the Contributor web after running a system link.  Any other suggestions?  We get the same "unknown error."

Jeff

[StuartS]

The issue of SQLOLEDB vs SQLNCLI changing for this "Unown Error" with system links is something we have experienced in our production environment.  This is on 8.1.

Cognos have advised us that this is fixed in 8.4.x.  Your posts suggest not.

You are right that the concept of a PAD changes from 8.1 to 8.4 as you now have planning store and so the TN is partly redundant.  (The TN may have come from our case)

The only comment I can make is have you contacted Cognos Support and raised a PMR/SR.  This was supposed to have been fixed.

[jeffowentn]

Ok, so here's the deal.  We had several issues going on at the same time.  I believe this issue was completely resolved by re-configuring the datastore and the application databases to SQLNCLI and stopping/starting the services on all servers in the environment (tested this after the first attempt, I believe with only correcting the order of stopping/starting the services).

NOTE:  When changing the datastore configuration, you will be asked about the xx number of other databases (app's and publish containers) in that datastore.  We said to change all of them to SQLNCLI.  In the end, this worked in our favor since we have more app's than publish containers, but the publish containers should remain SQLOLEDB.