DSXchange

See also these routines for other possibilities.

I don't think the IPC stage helps in this design, because the Link Collector creates a process for itself and therefore uses inter-process row buffering necessarily. I would recommend removing this stage from the job design.

Format is only relevant for display; the decimal placeholder character is not actually stored. However, it is important in calculations. If you are using code page 1252 then you must use "." as the decimal character, because that's the defined decimal placeholder character for the "US English" local...

By doing so you lose any job log purge settings you may have had.

No, that's sufficient. Use a Wait For File activity in a job sequence that waits for the trigger file to appear, then whatever else you need is downstream of that in the job sequence.

Not until you are more specific about what you mean by "external" sort.

The other three (input link sort, Sort stage and inserted sort) all use the same tsort operator.

Please compare your BuildOp code with the code generated by compiling the Transformer stage. Did you do anything differently?

So does using the ODBC driver for text file, with much less hassle.

Define your metric of "performance". Without that who can say whether "performance" will reduce (whatever "reduce" means in this context)?

Why do you think that a Build stage that performs exactly the same task as a Transformer stage would run at any different speed?

Hereis probably the best. You probably also need to lay your hands on the Orchestrate manuals, which can be had for the asking from your support provider.

Yes/no/maybe. Remember that each Transformer stage instance (there are four if you are running in a four node configuration) keeps its own, separate, count.

If it's VarChar ALL of the values in the IN list must be quoted in single quotes.

The table names are different too, and there are hundreds of them. No documentation appears to be available.

By "hash" I assume you mean "hashed file". Your "solution" could also be implemented using a database table, but it rather defeats the purpose expressed in the original question, does it not?