DSXchange

Okay, thanks. Not sure when I'll have time to sit down and help with this again, but will ponder it and still perfectly willing for someone else to chime in! :wink: Just as an FYI, there's no need to quote everything all the time, simply use the Reply to topic link at the top/bottom of every page un...

Okay, that site was blocked where I work so finally got a chance to look at the images you uploaded. First question: I assume your target table should not include those "Voice" lines and the column header names record, yes? Do you have anything for a constraint on the outgoing transformer ...

Those settings tend to limit the number of running jobs by causing any over the limit to blow up... and throw very specific errors pointing to them as the culprit, from what I recall. They're not the issue. And realize that the "resource issue" isn't confined to just what DataStage things ...

Unfortunately, no. I've been an Informatica developer for the last seven years and have no access to DataStage. Someone else may be able to help in that fashion or provide some advice I may have missed. Or you could try explaining just how close you got. :wink: If it would help, you can upload scree...

Did you get this worked out?

Ah yes, the proverbial question - what changed? Obviously something did. Typically, when I see someone post about seemingly random issues with jobs not starting within the timeout limit but then run fine later, it is almost always an indication of a resource issue on the server. So I have the same q...

Before Ray comes along and says something, they are hashed files not hash files. :wink: I would also note that "best practice" suggests you should only set the one specific hashed file to 64bit, not every single hashed file on the server, which is what happens when you change that uvconfig...

Did you try putting something like "code 139" into an exact search here? Many others have dealt with that message before, hopefully something here helps.

Probably best to run the job on a single node to accomplish that.

From what I recall, these "nuances" are explained in fairly complete detail in the documentation, yes?

Hmmmm.... shouldn't you be running the "fix" job on a single node?

In order to preserve the value of a stage variable row over row when it shouldn't change, you set it to itself. Typically that would be incorporated into your "change detection" logic as something like this: svVoiceUsage: IF <value should change> THEN <compute new value> ELSE svVoiceUsage ...

You create the "new" column in the output link of the transformer and assign the value of the stage variable to it as its derivation. Does that help?

At a high level: a transformer and a stage variable to capture the number and then to assign it to all of the following records until the next one shows up.

Difficult knowing how to help without knowing if the quotes are being stripped (and by which layer) or if something else is going on. Any chance your DATE string doesn't match the format mask or that you captured to the job's log the actual ORA error? And out of an abundance of curiosity, have you t...