DSXchange

As Roy notes, you overcome this 'performance issue' by running the sql once ( not once per row )and storing the result. Then it's up to you how you leverage that stored data. Sometimes you can kind of turn a job 'sideways' and use this as a stream input. Typically, though, this would be stored in a ...

I've seen errors like that when working with shared containers. I've found it better to promote the shared containers in a separate step before then promoting the jobs that use them. Avoids weird problems like that. When it prompts to include them aferwards, just click Ok without selecting them again.

That's the "value of the row is" informational message I was speaking of that is posted along side any errors, not really an 'error' message, per se.

They are always truncated at a certain size.

Not sure why it didn't work, but the double-quotes would go around the entire path, not just the one piece with the spaces in it.

And a small nit, it's not the 16bit path versus the 32bit path - it's Short (or as Ray noted the '8.3') filenames versus using Long filenames.

Write Cache? Nope, would have mentioned that. Posted on ADN? Why - the same people that would reply there are already here. Ray, I'm sure any before-stage subroutine would have logged its message well before this warning. It was quite some time into the job - probably after it had processed 85% of t...

For whatever reason, only columns up to an including CW_TELEPHONE (that is, the first 20 columns) are being used in the INSERT statement. Unless something has changed since it was originally posted, there are 34 column names referenced in the Insert statement and 34 distinct parameter markers as we...

No, the error seems to be specific to the hashed file. First post describes the job. All we're looking at is a Transformer with two stream links and a reference link. The reference and one stream both access the same hashed file. The other stream link writes to Oracle. I changed the link names in my...

I'd also be curious if you are doing anything 'unusual' in the Where or Other clauses - like referencing any parameter markers there.

That message is basically warning you that DataStage cannot find enough free memory to cache the hashed file, so that you are aware that it will therefore be read from disk (presumably more slowly than from memory). Understood. Any thoughts on why this would happen part way through a run when writi...

Did want to add that (like a good boy) I searched the forum for previous postings on this subject but didn't find anything that helped.

For the record, it is not a disk space issue, something that seemed to come up in the other threads.

Ok, I'm confused. Simple job that takes a prebuilt hashed file of existing keys and reads it as a reference lookup to drive an Oracle stage for inserts and updates. It also writes any cache misses out another link to 'the same hashed file' so that downstream jobs can leverage the information. The re...

From what I recall, the equal signs are only used for 'parameter value' pairs when actually running a job. Your problem may be as simple as the fact that the option is -lprojects and your post shows you used -lproject.

The only place that 'the text of all database error message' exists is in the job's log.

If you are expecting rows to 'flow through' the Sort stage, then you are mistaken in how you think it works. The combination of a Sort followed by an Aggregator will never work 'serially'. The Sort stage will take all rows from the source and sort them before producing any output. The Aggregator may...

Sure. Actually, that kind of thing (dependencies between different 'sections' of your job, that is) should be handled automatically. Best to post an actual image of your job design, Travis, if you don't mind. Check the next to last post on the first page of this post for an easy method to accomplish...