DSXchange

They're the same tsort operator under the covers. The stage just makes it more 'visible' in the job and gives you control over the parameters the sort can use.

I'm going to assume it's a resource issue, a simple example of attempting to run too many jobs at the same time. Can't tell from what you posted - are you using a 'wrapper script' that AutoSys calls and which in turn issues the dsjob command? If so does it check and report the return code from the a...

wrynkows wrote:How do I switch to RTLogging.

You could always search here, been discussed quite a bit. One example here.

Not really sure how. Welcome to the Wonderful World of Floating Point... it seems that someone made a less than ideal choice as to the target data type, unless there is some reason why it needs to be a float? They always complicate things. :( Oracle even recommends you do not use FLOAT as a data typ...

The duplicates could be against existing data rather than constrained to the input data. Of course, you haven't clarified exactly what it is you are deleting in your before SQL...

The Column Import stage would be one choice. But it looks like your file is being misread by the Sequential File stage rather than anything the Modify may be doing, so I'm not sure going that route would fix anything.

Looks to me like you are dealing with a signed CHAR. Sorry but I have no documentation here - is there some way to specify it is unsigned?

Doesn't seem to be one of the 'Asset Types' supported:

http://www-01.ibm.com/support/docview.w ... 443&aid=94

The short answer to your question is you can't. Job Parameters are set at runtime and cannot be changed. Now you could use a stage variable to track either the parameter or an override value derived while the job runs but I'm not sure if that helps you or not. Not sure what you mean by "so that...

Not a quote issue. Your error: ORA-31603: object "#SOURCE_TABLE_NAME#" of type TABLE not found in schema "DFFSSD" shows that your issue is the fact that the job parameter is not being recognized, so it remains untranslated. How are you building that select statement? You'll need ...

I noted that the Folder stage was a bit of a pain to use as a target because you need to send the entire output payload to it at once in a single record. Is that what you ended up doing? Hard for me to tell from what you posted.

Is it working? Then yes, use whatever it takes to uniquely identify a row - the PK, ROWID, whatever. And I put temporary in quotes as it wouldn't be a true TEMP table but rather a work table you truncate each run.

Use a 'temporary' table.

iq_etl wrote:Is there an assumption that should be made to include CHAR as well?

Nope. CHAR fields are always padded to full length, that's just the way the data type works in any database / tool. This option is only valid for variable length strings as the documentation notes.

Well... how did you set up the stage? What results did you get?