DSXchange

This post might help. There are others as well that an exact search for JOBTYPEIND would turn up.

You are going to get differing opinions on that and Google will happily enlighten you on "collisions" in MD5 hashes. For what you need, the odds that a hash on the same key for different values would somehow be the same are infinitesimal. And there's no need to worry about them being "...

What exactly did you try and what about it "doesn't help"?

I think doing it through a CDC or SCD will take a long time as job would be comparing 25-30 columns if key value matches to see if there are changes. My suggestion? Rather than think something may be a problem and avoid that approach - try it. Consider those other options if your concerns become a ...

Just checked the docs and it doesn't seem that the ODBC Connector requires that either. So I would just double-check the partitioning method and column that you've chosen in the stage and then compare that to the partitioning that you are doing in the job itself.

I would also suggest involving your official support provider, see if they can help here. Let us know what, if anything, you find out!

Never done anything with it but my understanding is "there's a service for that", meaning you'd need to investigate their API. Do you have a technical contact there that can help? Don't worry about the "from DataStage" part, just first do the "read Excel files from SharePoin...

These kind of things are almost always bug fixes, things that you thought were "working fine" in older releases but were in fact taking advantage of said bug. Fix the bug in a newer release and bam, all fall down. You're going to need to get into the weeds for this. What are the native dat...

Is your source table actually partitioned? Sounds like the answer is no.

What about the Data Rules stage? Wait, you can't honestly be thinking of migrating from SSIS to DataStage version 8 are you?

With no other answers or details forthcoming, all I can say is "hence the problem". Check it on the UNIX server. Where will this file be consumed, UNIX or Windows? That will drive the settings you should use.

These examples are meant to show us three records in the source and target? If so, the final delimiter in the sequential file has no bearing on that aspect of your example, that is controlled by the Record delimiter which is by default to a UNIX Newline from what I recall. What is yours set to? And ...

See if this post helps. There should be others as well.

It would seem the answer is no.

Hopefully in the interim you've engaged your official support provider.

Ack... noticed the "l" and meant to mention that as well, then got sidetracked. Thanks. :wink: Rather than simply throw more nodes at it to 'make the job faster', my first pass would be to ensure the current job design was as optimal as possible for the task at hand. Once there, throw more...