DSXchange

iHijazi wrote:Look up stage with so much data can lead to memory leaks/corrupted data.

Can you please provide some proof of this assertion? It is not something I have ever encountered.

You're probably correct. Have you tried re-booting? If yes, and that didn't work, have you tried re-installing the client software?

Incidentally, using COUNT verb probably doesn't load anything into memory, much less the DataStage cache. COUNT is typically resolved from the count of records stored in the hashed file header (unless a current write is open on the hashed file, which can be determined from the group lock table). Loa...

ODBC works perfectly well with MySQL, even when DataStage is on UNIX.

If the condition is not met, the Lookup stage does not attempt the lookup. What happens after that is determined by the "condition not met" rule, which has the same four possibilities as the "lookup failed" rule.

Note also that PA entries in VOC can be created by saving two or more commands from the Administrator client.

You have a hash partitioned table in Oracle, but not enough memory allocated for the Oracle processes to build the hash table in memory. As noted, involve your Oracle DBA.

Welcome aboard.

All you've told us is that View Data doesn't work with XML data type, which is not really a surprise. Does the job process these data?

Ignoring the processor, Windows 7 is not a supported operating system except for the client components.

Seems to me they've managed to introduce a memory leak into these functions. Definitely needed is a bug report through your official support provider.

Your sequence has a job activity set to "Run" rather than "Reset if required, then run", and the job itself is not in a runnable state for whatever reason (probably an Abort on its previous run).

It would be useful to run the Performance Analysis tool over this job.

The point about IsValid() is that it tests a string. There's no point trying to apply StringToTimestamp() until and unless you're confident that the string contains a valid timestamp.

Not via a "where used" analysis.

You could possibly interrogate the repository - there have been example queries posted on DSXchange over the years.

Show us what you did in the External Filter stage's command. I would be fairly confident that one can, indeed, generate a different record schema on the output (and therefore can generate values that were not input).