DSXchange

Or just do as Ray suggests. Heck, there may not be anything about this Excel reading job that really "needs" to be done in Parallel and a Server job could have it done while PX was still getting its pants on.

So... do you still need help with this? Wondering why it is marked as Resolved without a reply.

On the topic of the dsenv information, you're probably just missing the proper "source" syntax so that the contents come into your current script's environment. Typically it would be: cd $DSHOME . ./dsenv In other words you cd to where it lives and then "dot space dot slash" it. ...

OK, that's good. You might be surprised at how many people don't do that first to ensure they have the syntax working before it gets scripted. And with that working for you, it rules out your installation being any kind of corrupted. Then it would seem you just have an 'environment' issue and those ...

You can certainly arrange to have any of that information written to the log but as noted, except for what Ray mentioned, it's not there by default.

lewap02 wrote:Could this mean that my DataStage installation is somehow corrupted?

I doubt it. Have you tried / been able to do an import from the command line manually, as in outside of your script?

This is expected functionality.

Of the four columns in your example, which are the "key" columns? Or if those are all key columns are there other columns in the record? If "similar" records means "exactly the same" records then you can do as ssnegi posted. If, however, your key fields are a subset of ...

But isn't ODI more of an ELT tool and built around PL/SQL or am I thinking of something else?

Interesting... you must be a new incarnation of Cherry as you've posted here 107 other times since 2005 asking questions about a tool you don't have. :wink: As Ray notes, it certainly is one of the tools out there that could handle your volume. If you don't mind paying someone to have done the resea...

Transformerphobia is overrated.

Well... it seems we already have the shenanigans.

Or we could just work on finding a proper solution.

Well, that sucks. According to the documentation what Mike thought turns out to still be true - those "variable width" time formats are only valid for the import operator. "Where indicated the tags can represent variable-fields on import, export, or both. Variable-width date elements ...

Some quick answers... 1. They will import directly and should not have to change. 2. See #1. 3. I don't recall it being deprecated, would be shocked if it is any kind of gone. 4. See #1. 5. It's as straight forward as that. 6. Yes. Was going to write up something more comprehensive but let's just le...