DSXchange

Then the only way it will have a VOC pointer is if you explicitly create on. And you'll need to do that before you can run ANALYZE.HASH on it.

What! Server job! No freak'n way!

<wink>

ray.wurlod wrote:I do (understand the fear) but disagree totally with it.

Which is, of course, exactly what I meant. Totally disagree with the notion that they should be avoided at all costs, out of fear or skill set concerns or... what-knot.

Try it... and if it doesn't work, then fall back on one of the other options posted.

That's too bad... and #1 is the option that Ray was referring to.

I really, really (really) do not understand the fear of Server jobs, especially in cases where they supply the perfect solution to the need.

Hopefully you created a modified version of ExecSH (like ExecSHFatal) rather than change the delivered one that everyone uses, yes?

OK, your "two jobs" is a workaround of sorts but there is absolutely no need for two jobs to do something so simple.

That would be a question for support.

Umm, yah... thanks for that clarification, Ray.

Replace is not the same as truncate. Google for 'oracle sqlldr truncate'. I don't believe the truncate option is supported through the GUI, you may need to do it as a separate step.

Hmmm... very interesting. Anyone know for certain?

A Server job writing to a Folder stage can handle that. As (technically) can the XML Output stage, it doesn't even need to be XML for the Trigger Column there to help you out.

Right - both processes, unzip and 'untar', will need to support sending their output to std out and then you'd need to pipe them together straight into your job.

Any kind of an "motd" file out there somewhere, perhaps?