Oracle Enterpise Stage Warnings

Post questions here relative to DataStage Enterprise/PX Edition for such areas as Parallel job design, Parallel datasets, BuildOps, Wrappers, etc.

Moderators: chulett, rschirm, roy

Post Reply
gerardp
Participant
Posts: 7
Joined: Fri Jul 08, 2005 5:27 am

Oracle Enterpise Stage Warnings

Post by gerardp »

Hi,

I've run into a slight problem/feature with the Oracle Enterpise stage. When running a union query within this stage I received the following warning relating to the column AGRMT_NUM (which is set in the stage to Integer):

Code: Select all

 oraIssue: Column AGRMT_NUM floating point decimal not fully supported.  Adjusting scale. 
The column AGRMT_NUM is normally imported as an Integer and this is reflected in the imported orchestrate schema definition for the table containing this column. Non-union queries that use this column do not produce these warnings.

Therefore in order to avoid this warning I split the union query across two Oracle Enterprise stages both flowing into a Funnel and the warning disappears.

I couldn't find a post on this so hopefully it will help someone out or maybe someone knows why this warning is being produced.

Cheers,
Gerard.
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

Use a Message Handler to demote this warning to informational. It's basically warning you that some loss of precision in the least significant digits can occur because the floating point number being delivered is being converted to a decimal data type with a limited number of decimal places (compared to the theoretically unlimited number of decimal places that a floating point number can contain).
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
gerardp
Participant
Posts: 7
Joined: Fri Jul 08, 2005 5:27 am

Post by gerardp »

Unfortunately I'm using 7.1 - no Message Handler.

Do you know why this data type conversion is occurring in a union query and not when the same column is referenced in a non-union query?
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

The data types in the result set of the UNION query should match those in the SELECT clause of the first SELECT statement in the UNION.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
gerardp
Participant
Posts: 7
Joined: Fri Jul 08, 2005 5:27 am

Post by gerardp »

That's the strange thing. The UNION query is 2 part and each part on its own gives a resulting data type of Integer(6) which the Oracle Enterprise stage accepts without warning. It's only when in a UNION query that the resulting data type appears to be Decimal(38,10) - hence the warning. The Oracle stage sees the resulting data type differently.

It looks like the resulting data type of an identical column in a UNION is different to when in a non-UNION query.
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

Oracle has never been horribly consistent externally with numeric data types. Adjust your metadata to match what Oracle generates, and this ought to eliminate the warning. Adjust the data type explicitly in your job.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
gerardp
Participant
Posts: 7
Joined: Fri Jul 08, 2005 5:27 am

Post by gerardp »

Just revisiting this post...

I've found that the Oracle CAST statement helps to eliminate these errors.

For example,

SELECT CAST(acc_ref AS NUMBER(13)) acc_ref FROM
(SELECT acc_ref FROM .....
UNION
SELECT acc_ref FROM .....)

Thus forcing the Oracle Enterprise stage to see the field acc_ref as it's original data type.

This also works when you have aggregate functions (SUM, COUNT etc.) where the Oracle stage also seems to assume that the result is a floating point decimal.

Gerard.
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

Useful knowledge. Thank you.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
csrazdan
Participant
Posts: 127
Joined: Wed May 12, 2004 6:03 pm
Location: Chicago IL

Post by csrazdan »

Awesome workarround!!! It is better than mine.

This is what I have been doing for some time:
1. Add function TO_CHAR(COLUMN_NAME) in SQL Statement.
2. Adjust the datatype for the column to VARCHAR
3. In the transformer stage use StringToDecimal function to convert the datatype back to Decimal.

Thanks...
Assume everything I say or do is positive
Post Reply