DSXchange

I'm noticing something and want to confirm it here. When using the Oracle Enterprise stage in a PX job, I seem to be seeing a couple of behaviours that threw me for a moment, the first of which is PX looks at the actual table metadata for things like the "Nullable" attribute and doesn't ca...

It probably works fine but then they get added right back on. How about more details about what exactly you are doing where and what the end result is you are trying to achieve?

What you've done is perfectly fine as long as your select ensures it always matches that format with two digit (zero filled) months and days. That is the timestamp format you want for generated Oracle sql and since you are already in that format, with the exception of the milliseconds, best to just ...

Creating / running a dynamic number of MI jobs from data is fairly easy, a Sequence job with UserVariables plus Start/End loop stages can do the trick, as can a Server job leveraging the UtilityRunJob() function. The problem is when the jobs all need to run in parallel, which I assume is the ultimat...

I have no clue, hence the question. Just wanted to make sure there was no assumption of "64bit-ness", which is a common issue we see here. If IBM told you it's 64bit, whom am I to argue?

What hardware / OS are you running? With very few exceptions DataStage is 32bit, just because you are in a 64bit environment doesn't mean every app you run is 64bit.

Oh... "a forum ". For a second I thought you said that this was one of the few times this forum has actually helped you solve a problem.

Native range lookup, yes - PX only. You do it in Server different ways, which should all be found by an exact search for "range lookup" where job type is server. The UV stage sitting on an account-based hashed file (so you can use 'sql') is one such solution noted out there. What problem ...

Let's ask Ernie, he'll know! Ernie! Ernie?

You found them where, exactly? Seem like trace files for "ORBRas" whatever that is.

For the record, there is such a thing in a Server job: COMMON storage in a routine. As long as the stages you need to use it in are Transformer stages, it will support holding a value across multiple ones. With some caveats, of course.

That would be a job parameter. That means you need a 'pre-job' to do the selection and pass it to the job that needs to use it.

Interesting. Thanks for those clarifications, guys.

Right, dang was going to ask that and forgot. As noted, do you have this problem with all web services or just this particular one?

Will the output metadata / columns always be the same, regardless of table or query logic? If so, perhaps the "sql file" option would help here, leverage a job parameter to drive which one to use at runtime.