DSXchange

To avoid 2dn and 4th warning, you can change your target field as Nullable - yes or use the same modify stage to handle_null().

So its is all you need to check the availability of unprocessed data and based on the result you need to trigger the job. So how you define the unprocessed data. Is it the data left back in the tables? If so do a rowcount, and if it is positive trigger the job. But your earliar post shows that you n...

Isnt it not possible by message handler?
Or if it is metadata mismatch, collect it in reject link and add a transformer to "Abort after 1 row"

Still I doubt with the version

Job Sequence is also a part of selection criteria. Hence you can compile the sequence either through Multiple job compile or though DSCC.

Also the first warning tells you that the key value in the lookup data has duplicates. Either remove duplicate or handle the duplicate with the option avaialbe in Lookup.
For the second error, check with the "Condiiton not met" and "Lookup failure" options aviable in lookup stage.

You can check with this example given by Craig on Oracle Shared library.

If by any change, this is true reason on datatype, theoritically, I would guess, it might be due the timestamp avaialability.
Timestamp may need to be converted into internal value of datastage while processing and converting back to the original value.

parag.s.27 wrote:Hi,

Actually i mentioned in my post that i want to retain 1st value...

Balaji also gave a solution which was unnoticed.

preprocess the file using unix uniq command in before job subroutine or in filter option of sequential file

As mentioned that may be due the server over load by triggereing 12 jobs at a time by a JobSequence.
You can try to give pause between job which are called.
Search the forum from more information.

Perhaps related to the network usage...
Again it doesnt come under datastage monitoring.

And start investigating why it turned out to be empty.

What is the query used?

Was your source and target are in different network?
Do you find any difference if the target table is replaced with a sequential file?
If so was any index build on the columns of the tables on which Insert is taking place? If so dorp the index before loading and recreate after loading.

Double click on the column grid in the metada on the output tab, you will get the properties to edit.