DSXchange

Add two lines to uvodbc.config in the project directory. The space either side of "=" is mandatory.

I trust that you created a System or File DSN, not a User DSN. DataStage can not make use of User DSNs.

Welcome aboard.

Is DSN1 recorded in the uvodbc.config file in your project (on the server)?

Welcome aboard.

There's no log file for startup errors until you execute the following operating system commands. To get an actual startup log, simply redirect the outputs from the uv -admin -start command.

Welcome aboard.

Please post the entire error message. I'm sure it's longer than what you've given us. Also, please use copy/paste to do so, so as to avoid transcription errors.

Can you connect with DataStage Administrator client?

Have you set up DataStage role-based security (in Administrator client) for this project?

How about using your Information Server administrator user to log in?

Update is always - and necessarily - a slow operation. Even insert can be slow if there are many indexes and integrity constraints to be checked.

Separate your inserts and updates into separate streams, bulk load the inserts and do the updates subsequently.

When you run a job from a DataStage client, your agent process on the server (dsapi_server or dsapi_slave) is the one that actually issues the request. These inherit their environments from dsrpcd, which creates an instance of dsapi_server for each successful connection request from a DataStage clie...

More specifically:
1*8 + 0*4 + 1*2 + 0*1

Have you tried it?

You could certainly form all files into one in a before-job subroutine, and you can certainly read multiple files with a Sequential File stage, but I do not think that the Complex Flat File has this capability.

The command that failed is SQL and requires a terminating semi-colon.

None of which I am aware in parallel Transformer stage. You could readily write your own. You could use Oconv() with "MB" in a BASIC Transformer stage.

Sounds like what you really need is two job parameters - one for the file name and one for "elsewhere in the job". Your script/job sequence can take care of the casing.

If you're reading values from a multi-valued field you still need to specify the field number. For example ColumnNames<1,n> where field number is 1 and value number is n. But, if you Raise(), then it's field numbers you're extracting, for example ColumnNames<n>

What is the grain of this time dimension?

In every query engine I have ever encountered, the selection is completed before the sort is attempted. This is so that the smallest possible number of records can be sorted.