DSXchange

If you read the messages as "Move to work" queue and propogate the binded MsgId to the DTS stage.. it should move only records that failed to the work queue.

are you saying you need $LND_PWD to be the value of the paramter LND_PWD .... it wont be possible. You could create a user defined variable $LND_PWD and call that as a paramter in your paramset.

if you can be flexible with length/solution and its all about generating a randow number, try generating a unique value using a combination of something like inrownum||systime||random() or something that makes it unique ..

If your target database is compatible with a DTS stage (and ofcourse if you have it and if your release support it) you could use that - and messages are handled within the job the way you want it without any additional logic. But in the end i guess it comes down to what the business want you to do ...

are the number of columns in the sql query dynamic ? if its always 3 columns? What do you mean by process the data ? Would it be different for each table the data is extracted from ? You could fetch the value in column D querying this table from a sequencer and pass the output sql as a parameter to ...

are the number of columns in the sql query dynamic ? if its always 3 columns? What do you mean by process the data ? Would it be different for each table the data is extracted from ? You could fetch the value in column D querying this table from a sequencer and pass the output sql as a parameter to ...

if I were you - for something that contributes to the uniqueness, i would rather use something like a surrogate key generator or an equivalent logic instead.

Can you not run your job in "Keep" mode and then flush the queue once the jobs runs finishes ?

APT_DISABLE_COMBINATION

Use it wisely ..

Unless you are going to reuse the derivation more than once its better off to do it straight in the column derv rather than a stage variable.

Chandra

ACC_NO - Partitioning, Sorting (Asc)
REC_NO - Sorting (Asc)

Is what you need to have before your xfm stage.
This would certainly work for your requirement.

Sorry, I guess thats a silly question - since you have already used the same metadata to do seperate INSERT/UPDATE query tests. Could you try deleting that stage and redoing the properties with a new one to ensure you havent got anything hanging in it from another query/job if you copied the stage f...

what are the column names in queries that get generated.. im hoping none of them are oracle reserve words

I would try running the job sequentially to ensure that you have the stage variable logic right first before being worried about the partitioning.. (i know not ideal) But you could get one issue out of the way.. You could still Hash it before the xfm on ACC_NO, REC_NO usage as sort only... That will...

Sorry my bad.. Didnt see the OS.

not sure about the reqmt but.. Since you using the sequential file... you could add the "rowNumberColumn" option and see if that helps you..