DSXchange

Still... are you using job parameters in your ODBC source?

That design is no different from creating two separate jobs that you want to run at the same time.

One.

zulfi123786 wrote:Got it resolved after a lot of trials and errors.

Excellent!

I remember that Ernie has discussed this before:

viewtopic.php?t=146687

GAMEOVER7 wrote:this implies a period long queue, so the results of incorrect information.

Can I assume that this means you are sourcing from an active system and over a 'long period' the data changes across the related set you are extracting and that is the source of your 'incorrect information'?

Thanks. Any luck with the login error?

<Updated and migrated to the proper forum>

<split out to your own post>

I had to guess on your particulars so please verify for us your DataStage version, if this is a Server or Parallel job and if your server is on Windows or UNIX.

As to the issue posted, I'd look into the "Login Error" first.

Does your WSDL definition have "include" tags in it? For example, like what is shown here?

Yes, it is perfectly safe to 'interrogate' (as in read) the legacy repository like that. Now, if you want to stick to the dsx method I would suggest something I used to great effect in the past. Chuck Smith has a variety of DataStage tools many of which parse a dsx export into something easily pushe...

You can, however, restrict the rows going into the stage. That or drop off the "unneeded" columns post stage. I would suggest the former.

So... out of all that, you just want to know how to count the files? If so, then we're just talking about 'group change detection' where you track the current and previous value of the group key (whatever that is) in stage variables and increment a counter when it changes, otherwise you leave it alo...

I'd also be curious what settings you are using in the Peek stage. By default it does not capture all rows...

How are you partitioning? Does the job work as expected when you run it on one node? If so, your partitioning is incorrect.

It's actually up to 50 records per account type, so no way to know how many output rows we're talking about here. And yes, the 'grid' aspect plays no role here.