Hi,
I am trying to create a new table and load the data from another source table.
Source table has 2 columns as
a Decimal(10,0)
b Decimal(10,2)
to create the target table, when i import this schema, i get
a BigInt
b Decimal(10,2).
So, in effect the target table definition for column a becomes Number (19).
Is there any way to retain the same definition of Decimal(10,0) for column a. One way is to manually change it, but it would be quite tedious as there are lot of columns like this and many tables like these. Also, would not want to unnecessarily increase the column size to Number(19).
Is there any specific reason for this to happen or is it a bug?
Also, for the table with such a scenario, i can not load the target using ODBC connection, as DS throws out an "binding" error which is a optional feature of ODBC. How can we set the DS to enable the optional features, so that it can load "BigInt" columns. Loading works fine with Oracle Enterprise stage.
Thanks in anticipation.
Enabling Optional Feature in the ODBC Specification, / Bug?
Moderators: chulett, rschirm, roy
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Decimal(10,0) has to be BigInt, because the largest possible four-byte signed integer (twos complement) is 2147483647 (ten digits): any ten digit number larger than this could not safely be construed as an integer so has to be something larger.
Ultimately this is the root cause of your problem.
You could export the job, edit the export file, and import the result. Only problem is that, internally, SQL data type is enumerated, so you'd have to determine the coding (the constant SQL.TYPE.NAMES in DSINCLUDE/DSD_BCI.H will help).
Ultimately this is the root cause of your problem.
You could export the job, edit the export file, and import the result. Only problem is that, internally, SQL data type is enumerated, so you'd have to determine the coding (the constant SQL.TYPE.NAMES in DSINCLUDE/DSD_BCI.H will help).
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Again, this is a problem with how Oracle see "Number" and how the rest of the world see it.
Why can't you just tell your DBA to change their table's metadata to Integer, as they should?!
After all, do you REALLY have to have 10 digits all defined and spruced up with a bow on top?
Number should not be universally used in Oracle, in my opinion. Only when you MUST define a scale, should you use Number. Integer, Long, and the like are sufficiently fine for ... numbers.
This will eliminate your decimal[38,10] problem, among other issues.
Why can't you just tell your DBA to change their table's metadata to Integer, as they should?!
After all, do you REALLY have to have 10 digits all defined and spruced up with a bow on top?
Number should not be universally used in Oracle, in my opinion. Only when you MUST define a scale, should you use Number. Integer, Long, and the like are sufficiently fine for ... numbers.
This will eliminate your decimal[38,10] problem, among other issues.