DSXchange

Hi,

Our current data warehouse Datastage applications are using MS SQL Server 2000 as backend database and we are in the process of migrating
to Oracle 10g. We found an issue while System Testing.

We have jobs that are reading from Complex flat file and loading it into ORACLE ODBC stage.

For a particular AMOUNT field (SQL Type DECIMAL , Length 11, Scale 2
and Display 13) source data value is 123456789.12 and while loading data
into Oracle Database using ODBC stage the last digit is getting truncated
and data is getting inserted with value 123456789.1

When we replace Target ODBC stage with DRDBMS stages (DBMS Type
ORACLE/ODBC) or Oracle OCI stage, it inserts 123456789.12 properly.

Are there any datastage functions or options available to avoid this data
truncation in Target ODBC stage?

For us to replace Target ODBC with Oracle OCI is like redoing all of our
jobs since we found this issue while System testing.

Thanks

Did you try increasing the scale and test it?

DeepakCorning wrote:Did you try increasing the scale and test it?

Yes, We increased width to 13,2 display 15. Data got inserted properly.

Thanks

ray.wurlod wrote:Could be time to mark thread as resolved, then.

We tried to insert data with other stages like Ora OCI and DRDBMS
by keeping same width 11,2 and display 13 data is getting inserted properly.

but our issue is, when we keep same width and scale (11,2 and display 13) in ODBC Stage. Its NOT working and most of our jobs are having ODBC stage.

Thanks

And?

You've got your answer - you will need to adjust your metadata for use in the ODBC stage, it seems. You can thank Bill Gates for that. Only question in my mind is: does it make a difference if you use the Oracle 'wire' drivers over the 'non-wire' ones? Which have you tried?

Rhetorical question, but why would you use ODBC when you have a 'native' interface available, in this case OCI? To me, ODBC is the 'interface of last resort'...

But easier to change databases subsequently when some smooth-talking sales person convinces management that dBase IV is the only database you'll ever need and it's cheap as well.

ray.wurlod wrote:But easier to change databases subsequently when some smooth-talking sales person convinces management that dBase IV is the only database you'll ever need and it's cheap as well.

Update - We have been notified by IBM that there is patch available for this issue.

Thanks

Good to know. If you can, please post the ECASE number for this patch, it will help others with the problem get the solution as easily as possible.