An important lesson was learned earlier this week, really its something I already knew, but it was useful to get a reminder of this. It was also useful to remind the customer of the same.
We got a call requesting help with an issue where Cognos Planning Analyst appeared to be behaving differently between the old server environment (IBM Cognos 8.4 RTM) and the new server environment (IBM Cognos 8.4 FP2) when running a d-link within Analyst.
Now I already know that Analyst is not the most technical of products, so to hear of such strange problems (i.e. the d-link not recognising the source of an ODBC connection) is quite unusual and can be quite frustrating to deal with. As is usual in such cases our client was convinced that the problem was within Analyst and attempts to convince him that the cause was unlikely to be with Analyst were seemingly difficult to push.
After a little playing around looking at the source CSV files and comparing them with those from the old system we decided that on the face of it, the systems were identical.
It appeared that the problem may have been to do with the actions the SQL code in the d-link source was trying to process. It was manipulating the data prior to inserting it into Analyst.
The first thing I tried was to remove the customised SQL code and use a straight forward select statement. This worked straight away. So the file was able to be read. Though what I then found was that the data brought back was not in the expected format.
Another look at the ODBC connection and a click of the “options” button exposed some additional settings where you can set the delimiter type, header cells and other formatting options for the text file. Once these had been set we went back to Analyst and opened the d-link to find that it magically worked now.
So this is an example of a problem that appeared to be the fault of the product which in fact ended up to be caused by incorrect settings on the ODBC connection. One worth remembering I think.
