DSXchange

This sounds like one of those times when you would not want to go with Auto partitioning and instead would want to explicitly control it. Rather than consider changing how the Oracle table is partitioned, change the DataStage job to match the table.

And then see if that indeed is your issue.

Seems like a strange requirement, why would you need to do such a thing? :? Not sure how simple this would be, regardless. Normally I'd say do this with "dsjob": first with "-ljobs" to get their names and then iterate thru the names using "-jobinfo" to see what state ea...

In other words - yes, use it for every field that could be null.

I assume this will work here:

Street:NullToEmpty(ExtNo):Colony

Once you cat a null onto a string, the result is null no matter the other values, so you need to avoid doing that at all costs.

Not without a better idea what kind of 'summarization' you're doing in the Aggregator. Are you grouping on the 8 keys you've mentioned? Doing what with the other fields? And by 'same amount on both hashed files' are you saying that the number of records pulled from the first hashed file is the same ...

Use the Contact link at the top of the page to send an email to the Membership Director. That or patience are pretty much your only two options, I'm afraid.

OK, so the whole 'logs are in the XMETA database' stuff doesn't apply.

I would suggest that if you can't get any joy from the Admin console that you find the internal job number for this job and issue a CLEAR.FILE RT_LOGnnn where 'nnn' is the job number and see if that helps.

To help with this and to cut down on the 'loop speed' add an Execute Command (or Routine Activity) stage inside the loop that does a 'sleep' for a user-configurable period of time.

sorry, but how does that help? We know it is 8.something, I want to know what the something is as that changes how logs are stored.

You show as a Premium Member, are you still having issues seeing everything? One thing to keep in mind, it is still a manual process behind the scenes AFAIK, not fully automated.

It's only enabled for account-based hashed files... or pathed ones where you've specifically created a VOC entry for them.

And if that doesn't help, give us a better idea what "it doesnot identifies the inserts ad updates correctly" means.

And this is 8.0 or 8.1?

What I've done is set it to run X number of times and set X to a sufficiently high number such that it (hopefully) won't end before your custom condition is met.

There's nothing documented except here, I believe. You can put "call sp_name" either before or after sql, typically before if the sproc is a target. Then you'll need something that does 'nothing' in the actual sql tab - delete or modify something you know will never succeed, this as a 'no-...