DSXchange

Try importing the table definition using Orchestrate orchdbutil facility, which is known to be more accurate.

Boa sorte! :D

7.5x2 was a whole heap of compromises held together by duct tape. Fortunately, duct tape is a very versatile substance. Version 8.0 is far more likely to be rigorous about such things as correct partitioning and sorting of input links when required. Try inserting Copy stages on the links between the...

Sounds like your job is only using one of the disks. If I/O bandwidth is saturated (100% busy), the CPU has no option but to wait, so the %Idle on the CPU will be well greater than zero.

"Slow" may only be an issue of expectation management.

Parameter names are case sensitive. You won't get DSJE.BADPARAM (-3) if you spelled and cased it correctly. Check again.

You probably don't need the value in quotes, either.

kaps wrote:This job runs in 2 other environments and fails in one.

What's different?

Almost four years to the day late, and in the wrong forum!

Please begin a new thread in the Parallel forum - any answer posted here will be wrong for parallel jobs, as they work completely differently.

Please do not post parallel answers to this post in this forum

... or you could create a Between() function. Which would do the same thing internally.

(If you had parallel jobs you could do this immediately with Key Change column in Sort stage.) In server jobs, you need to have your data sorted by this key, and use a pair of stage variables - one to detect the change, and one to remember the value from the previous row. The technique has been disc...

You folks are confusing genius with "experienced".

Merde.

Someone has deleted all your jobs.

Do you have a backup or an export?

How many times are you evaluating Substrings(cms_p11d.ORDERNO,1,1)? Seems to me a more efficient approach would be a stage variable, to evaluate Left(cms_p11d.ORDERNO,1) just once would be far more efficient. Use the stage variable name in your compound If..Then..Else expression. The logic breaks do...

Looks like there's something awry with the indexing in the DataStage Repository.

Are the six instances all in the same category?

Try DS.REINDEX all when you have exclusive access to the project, and report back whether the problem has disappeared.

Can you state your actual requirement in terms of what you want to get out of the Red Brick database? We're aware that the date comes from an Oracle database, and can probably manage that in a job parameter, but how do you need to use this date in a Red Brick query?

Sounds like some training might be in order. Not least training on how to use Code tags at DSXchange.