Hi,
there is a simple report showing the content of a database table.
The ID-column wihtin the oracle DB is defined as number(38, 0). Most IDs have a length of 38 digits.
When executing the report only the first 32digits are shown correctly while the last 6 digits are just zeros.
Eg. database contains the following ids:
20150918010105215071000000000011500072
20151210010105215071000000000012183606
When executing the generated SQL which is shown under Tools -> Show Generated SQL/MDX, the following id is shown:
20150918010105215071000000000011500072
20151210010105215071000000000012183606
When running the report the following id is shown:
20150918010105215071000000000011000000
20151210010105215071000000000012000000
When I open the lineage (rightclick on the id-field within the business-object-browser) -> Lineage
as well as within the Framework Manager
there for the business object the following parameters are shown:
datatype: decimal
precision: 38
scale: 0
size: 20
additional test-ids:
a)
10000000000000000000000000000011111111
b)
1000000000000000000000000000011111111 (one digit (a zero) less than a)
results into:
a)
10000000000000000000000000000011000000
b)
1000000000000000000000000000011100000
Well maybe the size is the problem but.
- it does not cut after 20 digits but after 32
- it does cut cut after 32digits independently the number
- what is size? I was not able to find any documentation about this wihing the cognos bi knowledge center and anywhere else.
Or is the problem that Framework Manager declares it as decimal instead of integer?
I am looking for a solution which does not contain to cast the value to string before displaying it within the report.
Thanks in advance.
Even havin 99999999999999999999999999999999999999 cuts after 32 digits to 99999999999999999999999999999999000000.
Any idea?
Honestly, I would open a support ticket. There are a lot of variables in play from database to drivers to internal Cognos number representation. They are a lot more likely to know than most of us what the root problem is and thus potential workarounds.
Large precision ORACLE types i.e. NUMBER vs NUMBER(20) etc are bound at the driver level as double. That type conversion can result in loss of value.
Known issue. Contact IBM support re when an improvement will be made available.
do you think the loss would occur on driver level even when sorrounding the expression with to_char() displays all characters?
but opening a support ticket sounds like a good idea.
hm, looks like I need to be a registered customer at IBM.
I dont have the credentials of my customer I am working for so I am not able to create a ticket.
Quote from: Kaspatoo on 13 Apr 2016 11:36:29 AM
hm, looks like I need to be a registered customer at IBM.
I dont have the credentials of my customer I am working for so I am not able to create a ticket.
You need to get the customer to raise the ticket...
MF.