DSXchange

Satish - I wouldn't say that your approach is wrong, but it might be over-engineered for what the original poster is looking for. We will need to hear back to see what it is they wish to do.

I think it might be faster doing 3 concurrent SELECTs and then joining the 3 streams in a link collector stage. The answer isn't definitive as it depends upon your DB configuration as well as CPU and IO specifics (also whether or not the DB is on the same machine as your DataStage server). Nominally...

The APT_CONFIG_FILE and its contents is central to PX. It is documented both in the Parallel Job Programmer's Guide and in the Parallel Job Advanced Programmer's Guide. I know of no environment variable called "APT_ORACLE_NO_OPS ", do you perhaps mean the "APT_ORACLE_LOAD_OPTIONS"?

kasgang - that is not sufficient information, it is like saying "sometimes my car won't start. How do I fix it". The pid number doesn't mean anything, so we will need additional data about the job and the aborts.

If you are doing a normal insert (versus a load) into your database, you can just stick with a simple INSERT and just not look for errors (which would happen if you attempted to insert into an existing key), this is probably easier than doing a lookup - although it depends upon the relative percenta...

This is the first mention of a varchar RHS column. If you explicitly TRIM that column and output it to a peek stage are the spaces gone? And then they re-appear when writing to your database? What database are you using?

Ray - I wouldn't bother trying to suggest using FTP, for some reason he has ignored all previous posts in this thread suggesting that approach.

If you use a varying length datatype make it bigger, since you aren't guaranteed that gzip/compress will encode a <cr> within 2000 bytes (although it is likely). I used a fixed length field such as CHAR(128) for my compressed FTP stage and ignored the error on the last row read in. You can also use ...

You cannot TRIM a char field. It has fixed width and will always blank pad to the fixed length. You need to declare a VARCHAR column datatype and then TRIM your original CHAR column into that.

Are you still attempting to FTP the file using DataStage? What have you defined as your FTP column(s) in the FTP stage?

What is the datatype from your dataset schema? Add a 2nd output link to your transform going into a peek stage with your TRIM() string and add a column of LEN(trimmed-string) and see if the results are as expected.

The trim function will always remove spaces from strings, so either you don't have spaces but other characters or you don't have strings - note, you cannot remove trailing spaces from a CHAR field, just from VARCHAR. What are your datatypes in the job and the table? Are you doing a TRIM() on CHAR fi...

I use shared containers with RCP that accept all sort of different column contents and count in different jobs, acting only on the columns used in that container. Usually I will pass in the names of the columns as parameter and then create/remove temporary work columns in modify stages in the shared...

The throughput of both options depends a lot on your database and table configuration and using LOAD vs. a more traditional UPSERT is not always the best solution. With a partitioned database you can get real parallel loading to separate partitions if you code your job correctly and that can signifi...

swades - you haven't stated if you are retrieving data from a hashed file or a database in your lookup. As mentioned before, if it is a database then you can put your OR expression into the SQL lookup. If you are referencing a hashed file then you need to do 2 lookups and then perform the OR logic i...