DSXchange

As noted, no can do.

So... you've got 10 files with different metadata that load to 10 different tables after some 'data validation' and you want to do this with one 'generic' job?

First you need to clarify your seemingly contradictory statements.

So... "the meta data will be different for all files" but "All these files do have the same table definitions". ??

Several choices. You can TRUNC() in your SQL to get just the date portion. Or TO_CHAR() them both to strings in YYYY-MM-DD format and compare them directly. Or use IConv() and then compare the internal dates inside the job.

Alright, fine. Next time do that without the intermediate shenanigans, please and rather than replace everything posted so far simply add a new post that clarifies your requirement.

No need for all that revisionist history as now existing replies can make little to no sense.

Give me a f'ing break. That kind of behaviour - going back and replacing your posts with random crap - falls squarely into the 'childish' camp and pretty much guarantees you a spot on the 'People We Tend To Ignore' list as who knows when you'll pull that crap again.

What?? You mean 'DoubleSecretProbation' isn't everyone's WAS password?

I am truly curious why anyone would have a "need" to "Identify the number of columns being used in each stage in a server job"? To what purpose? What problem are you trying to solve?

Perhaps if we attack the problem from a different angle there will be a better solution.

You should, however, be able to reset the job from the command line to the same effect. Can't check the actual syntax from here at the moment.

Interesting. So, no equivalent in the PX world?

You'd probably need to get something like that from the various vendors out there, I would imagine it would be fairly common for them to build comparison matrices of feature sets. I've been involved with companies using Control-M and Tivoli and they've seemed fairly comparable.

They certainly wouldn't be stored but I honestly thought it would ignore them during the process. If I get some spare time I'll double-check from my end.

No, that conclusion is incorrect. From what I recall, the commas shouldn't bother Oracle when loading into a NUMBER field. However, if every record had one column like this: "$5,757,194" it won't like the dollar sign and that should be your "non-numeric data". And of course a str...

OK, so which is it? when I execute the job it fails with "Too many columns in the file" error -or- after executing the job, the data is all distorted in the destination You shouldn't have any problems reading that, which the 'View Data' would show, especially if you can scroll through the ...