DSXchange

Define exactly what you mean by 'integer' format so that people don't spend time on the 'wrong' solution.

Doh... got distracted and sat on this post for too long.

You go, Ken!

Probably so. On the hashed lookups - is there really a need to load your entire Oracle tables into them? One 'trick' (aka Best Practice) is to only load what you need for the current dataset. I generally make sure that the key fields from the data that I am loading is also up in an Oracle table - th...

Ok... if it's in the SYS.MESSAGE table then why does DataStage report it as an "Unknown error 911"? Is the diagnosis that it is a space issue / segment violation correct?

But really couldn't figure out how the datatype changed while importing That's because a DATE field in Oracle is really a Timestamp in disguise and always carries a time portion. When it looks like it doesn't, that's because the time portion has been set to zeroes as we've discussed earlier in the ...

Ah. Thanks for the clarification... forgot the previous discussions were and/or related.

In other words, go talk to your DBA.

When you job fails again, reset the job from the Director and see if it logs an entry with 'From previous run...' in it. If so, double-click on that entry and let us know what details are in there.

Simple - concatenate a zero time onto the end of your date:

Look at the generated SQL in the Oracle stage. Note the format it expects the DATE fields declared as Timestamps to come in as. Transform your fields to match that format. Problem goes away.

In addition, last modified time is displayed in the Manager. For all objects, I do believe.

Not to derail this, but...

Ray, I could have sworn in the past you've said that DataStage was an odd duck in that it did not enforce any precedence when evaluating expressions? That it is, without parens, evaluated strictly from left to right. Am I mis-remembering?

Vincent is talking about the Sequential File stage in a Parallel job, which will automagically reject / not process any rows where the metadata doesn't match without raising a fuss. A Server job is different and will complain when there are mismatches. You can handle your problem by switching to the...

No, it's not ok.

A lookup is an equi-join where field = key and what is equal to null? Yup, that's right - nothing.

Any chance you are writing to any of these hashed files (or a hashed file) as well during the load? This is also a Prime Suspect when dealing with progressive slowdown in a job.