DSXchange

As suggested, Use TO_CHAR in the source and convert it into Char data type, pass it till the target, and User TO_NUMBER to convert it back to Decimal. Have you just tried with Decimal[42,2] and run the job (not just view the data)? Did you got any error? Would you be able to find the data in output...

we already created 300+ jobs in the server. Our data base is oracle, we need to migrate all the server jobs into parallel. No, you don't. There's no reason, just because you may have just upgraded to EE that now suddenly you 'need' to convert all of your Server jobs to Parallel jobs. EE supports bo...

Hi!

Ken Bland has a very cool little 'Utility' job (one amongst many) that will take Parameters from an existing job and 'seed' them into a new job. Note that this can be a single parameter or an entire 'block' of parameters. These are free from his website and part of his Job Control Utilities package....

'File Pattern' just means to use wildcards in the filename and, in essence, read more than one file in at a time. It has no bearing on the type of file, so of course you can use the feature with XML files. And there is no limitation on the number of files that I am aware of. Your 'note' is another k...

If your issue has been resolved, mark the thread as Resolved as well, please.

As noted, do an Exact Match search in All forums - you'll get almost a dozen other threads that mention your error.

You can't change the default but you sure as heck can change the values after it imports them. What happens when you make the metadata for that field Decimal(40) all the way through the job? No to_char, no StringToAnything, just pass it as a large decimal value with no scale from one end to the othe...

And keep in mind it could very very small, especially if created accidentally with a right-click and small twitch of the mouse.

Right, that seems to be the default metadata of choice for an unbounded Oracle NUMBER. Hence the suggestion to 'fix' it.

That's not the uvconfig file - that's the uvodbc.config file. Please check the file called uvconfig in the $DSHOME directory on both servers.

Have Faith.

The data type is number at database level. I'm assuming this means at both ends - source and target. And if it came out it sure as heck can go back in. Ray - NUMBER is not the same as NUMBER(38). I can put a 39 or 40 digit integer into a NUMBER field without loss of precision. I can put larger numb...

You'll need to wait and see if anyone else can help. Or call Support and open a case.

So try changing the metadata from Decimal(38,10) to Decimal(39) or Decimal(40). This is just a large Integer value with no fractional elements, yes?

Or at worst case use TO_CHAR in your source and then TO_NUMBER on your target side... shouldn't be needed, however.