DSXchange

I find that RTFM* is a good strategy sometimes.

* = read the fine manuals (clean version)

(Though there are some annoying lapses in the version 8 manuals.)

There's a grid for that in the Job activity from which you invoke the job in the job sequence.

The value you provide is the $CommandOutput activity variable from the upstream Execute Command activity, with appropriate Trim() or Convert() functions applied.

You're half-blind. The "%" character has a special meaning in a FMT mask (zero-fill) so, if you want one, you need to escape it.

Every stage has Help, every stage has either a chapter in the Parallel Job Developer's Guide manual or in its own manual. There is also an XML Best Practices document available (search the forum). Once you have completed your researches, you might like to post specific questions. However, DSXchange ...

As VARCHAR, since that's how the importer is seeing it.

All data can be managed as VARCHAR.

I assume that you are invoking the stored procedure from within a DataStage job. Therefore the value can be read by an Execute Command activity (perhaps instead of writing it to a file) and the command's output passed to the job as a job parameter value - after trimming any unwanted line terminator/...

Specify the "key" column (which then moves into the WHERE clause of the UPDATE statement). In this context "key" does not necessarily mean "primary key". Note, however, that if there is no primary key, there is the potential to update more than one record, if the same value occurs in your "key" colu...

Prove to me that it's valid, with a reference to a manual.

That it works is not proof - as I noted, invalid arguments can be ignored and take default values.

The first syntax is, essentially, invalid and so will default the third argument (to "B" or "T" - I can't remember which).

Then your metadata do not correspond to what's in the file, or you have not indicated in the CFF stage which field identifies the record type. With multiple record types I presume you have set up separate output links for each?

Would you care (a) to mark the thread as Resolved, and (b) to share your solution?

This looks suspiciously like this post - even unto the example cited.

Please continue all discussion on that thread.

In general no.

Two job parameters, for example jpStartDate and jpEndDate.

The SELECT statement then has the restriction