DSXchange

You have yourself a plain old ordinary sql query optimization task which really doesn't have much to do with DataStage until it starts returning records, at which time your Array Size setting with take affect. Other than that, it's all about explain plans, indexing, hash joins versus nested loops, s...

Try it, let us know.

The NOTFOUND link variable only works reliably with a hashed file lookup. For direct database lookups, you need to fall back to the Old Skool null check as you are doing.

Now that that is out of the way, we can get on to solving the real problem. Can you perform a manual ftp at the command line from the DataStage server to your ftp server? Have you involved your admins, verified that ftp is possible between the two?

OK, sure, anything that makes either the Universe or XMETA repositories full would be a Bad Thing.

No, there's no impact on the performance of the jobs that I've ever seen. The performance of the job coder, perhaps, but not the jobs themselves.

We cannot as you have not stated the problem you are having.

However it is a perfectly valid varchar so unclear why that would have been "in vain". What is the data type in Oracle of the target field for that value?

Which is what I meant by my comment and which an exact search for 'Could not map table file' would reveal. Heck, one such post was started by yours truly, having seen this very error.

There are multiple ways to identify duplicate records regardless of source. What have you tried?

Usually, setting 'Contains Terminators' to Yes is all that is needed. What is different / unique to the 20% that are still causing you problems? Where exactly are these being 'dropped off' - does the stage not read them, your source reject them, something else entirely? Any warnings associated with ...

I would run that question by your DBA, that or simply change it and see. You can always change it back.

Try, let us know. What database?

Join the two tables directly in the 'unload' query, that giant 'in' list is about the worst way to handle volumes of that size.

Let's get this out of the way first - XP is in no way a supported O/S for the Server component, so not surprising you are having issues with it. And since it is attempting to run jobs, then you must have actually installed 7.5x2 rather than 7.5.2 as stated. Correct? No other 7.x version would even l...