DSXchange

BINDING is what is required.

Luckily for you, the ASCII code for "/" is 47 and the ASCII code for "0" is 48, so that your filter (WHERE @ID >= 0) will also exclude the control records.

... but you could adapt it to your own requirements.

This is the IBM message regarding Red Brick: We plan to ACTIVELY sell and support Red Brick V6.3 into the foreseeable future. We have NO plans to EOL Red Brick. We are continuing to see strong demands for the Red Brick product, and we are committed to supporting our customers on Red Brick for as lon...

It's not documented anywhere. The project template is - effectively - a regular project but without a VOC. Thus there's no way you can get into the DataStage environment in the template "project". You could, of course, create a pointer to the template's DS_ROUTINES table from another project, and th...

Are the fields nullable? If so, how have you set the Null Field Value property? The empty fields may be being read as NULL. What data are being imported into the job?

The corresponding D_* entries - but only the corresponding ones - do have to be deleted. You also need to delete the entries from the VOC table, which you must do - very carefully - with an SQL query. DELETE FROM VOC WHERE ID = '<<Hashed File name>>'; Next time use the DELETE.FILE command. It will s...

No database will allow you to control the order in which rows are stored in a table.

What you are asking for is simply not permitted.

Easier to process with a filter command in the Sequential File stage that reads the file. Use sed or awk or some other command that allows you to remove empty lines from a file.

Welcome aboard. :D Please post the contents of each of the files you mention, plus the exact and complete error message that you receive when you try to connect. Have you attempted to use any diagnostic tools, such as DS.CONNECT within DataStage or the testing utilities within branded_odbc, where th...

That only works in RetrieVe, not in DataStage SQL. What Arnd is referring to is that VOC contains D-type field descriptors F1 through F9, that can be used to refer to any field (from 1 to 9) in a record. You could certainly do this by specifying RT_LOGnnnn USING DICT VOC in your FROM clause; however...

What you want is exactly what DataStage does. The target database table, however, stores the records in whatever order it wants to. This is a fundamental property of relational databases; that storage order is irrelevant. It's not a DataStage issue. To get sorted data out of a table, the rules state...

Use stage variables in a Transformer stage to compare each row with the previous one in that column. If the direction of difference changes, then the answer is NO.