Admin link with A.Table reverting sign of some records

[KolKhoz]

Hi,

I'm facing a weird behavior of an admin link in Cognos 8.4: somehow it is changing the sign (reverting it) of some records when it populates them into a different contributor application. The funny thing is that it is only doing this for some eList items but not all of them.  ???

I've been checking and double checking both the model and the link yesterday but couldn't find anything wrong. My admin link is using an allocation table loaded from Analyst for the mapping of eList items. I changed it (a different allocation table file but the content is the same) in one link element and apparently it solved it, but the problem persists for other link elements.

Did some of you faced a similar problem? Anyone has a guess one what could be going wrong?

Many thanks,

[Jenny]

We have come across the same issue.  We ended up having to go back to manually mapping in stead of using the A-Table.  If anyone has found a solution to this problem it would be great to know... Help!

Thanks!

[JaromirSeps]

Hi,
and have you checked this with ibm? Is this a confirmed bug?
Jaromir

[KolKhoz]

Hi,
I logged in a call, but the first level of support wasn't able to understand what could be wrong. Again there are no error messages so there's not much to send them. And I keep on having this same problem on other links, for other applications...
I made a deployment export with data of the 2 applications and the link. I intend to send it to them so that they can replicate the problem and see what they understand from it, but it's going to take some days since it's a 5 gig file and we don't have an FTP server over here. I'll let you know if I get something.

[aa2288]

Error is not specific to 8.4, this situation have encountered even in Cognos 7 and 8.2. This specific behaviour is due to Breakbacks. You may be transferring data through Admin Link to some calculated items or to a detail item and simultaneously to a aggregated item. Negative numbers arise to make aggregate sum equal to zero.

[KolKhoz]

Thanks aa2288,

I started to think about this at first but I skiped this potential explanation because I thought breakback was not enabled in the related cubes.
But after reading your comment, I double checked it and indeed I see breakback is enabled in some of these cubes, so it could well be the reason behind all that mess. I will need to re-check all my admin links and re-test to confirm that; I'll probably do that next week.
But thanks again for the tip it looks like a good one! :)

[Jenny]

I am having similar issues as well with this.  I have to have my breakbacks and I have to have the conditional statements I have in the mode.  Is there any other work around?  Any help would be so appreciated!

[KolKhoz]

Hi,
I finally got the chance to test wether it was related to breakbacks or not, and I'm afraid this is not the answer. I disactivated breakbacks in my target application and rebuild an admin link for which I'm sure all dimensions are mapped from lowest level to lowest level, but unfortunately the problem remains, data turns negative.
I'm going to make some more tests with and without some access tables as Cognos advised it but I don't have much hope at this stage. I still think this has to do with A.tables since the problem started after I started using them.

[robmac]

Hi all,

I had exactly the same problem.  It's a known bug in 8.4 and was fixed in FP1

Hope this helps

Regards,

Rob

[KolKhoz]

Hi robmac,

Thanks for the info. I'm going to stop making tests for nothing then. And I'm definitely going to request this FP1 pack.

Could you give me the reference of your call with the Cognos helpdesk? I'd like to refer to it in my own ticket.

Many thanks,
Sylvain

[KolKhoz]

Hi robmac,

I had an engineer from Cognos on site today to look at another issue, but I asked him about it and he checked the config of our environment and actually Fix Pack 1 is already installed for us. So that's obviously not the answer to our problem here, but I'd still be curious to know more about your corespondance with the helpdesk.

[aaday]

Yes - we have seen this one and it's NOT fixed in FP1

[aa2288]

The -ve numbers are due to modellogic used. I am not sure any fix will be able to resolve that. Maybe somewhere there may be aggregated items which are being transferred through a link which cause negative numbers in individual items.

[robmac]

Hi aaday, et. al.

It may have been a hotsite fix that resolved our issue - but my understanding was that all of those hotsite fixes were supposed to be included in FP1.  I was certain it was listed as a known bug in one of the fix lists.

At any rate, we used to have exactly the same issue as KolKhoz mentioned but we don't anymore.

Rob

[wonderkid]

We've experienced the same issue. We were told by Cognos that it's a bug which has something to do with clicking the Cancel button when accessing an Admin link that uses an A-Table. Sounds trivial, but that's seemed to be the issue in our environment. When we have hit the cancel button by accident, we've had to open the Admin link, break the connection which uses the A-table, and then close out of the link (don't hit cancel). We've then had to re-open the Admin link and re-map using the A-table. This usually solves the problem (occassionally the first time doesn't take and we'll still get reverse signs, but by the second attempt ths issue is usually fixed).

[ovo]

Should be resolved in 8.4 FP2

[Beast]

Been struggling with the exact same issue now for many months and almost going mad  >:( Did the install of FP2 resolve ?

[Rutulian]

See PK92884 in the fix list for FP2 http://public.dhe.ibm.com/software/data/cognos/support/docs/en/planning/8.4fp2/IBM_Cognos_8_Planning_8.4_FP2_Fix_List.pdf

You should be able to avoid this happening by never clicking 'cancel' when editing admin links.