DSXchange

Reset the job in Director. Read the event marked "from previous run...".

With a more appropriate sed or awk script, of course. Might be time to invest some effort in learning these tools.

Clar the status file. The reset operation appears unable to find the wave number (the internal unique number) for the run that aborted.

You should be able to run in File Mode, but that would of course introduce a bottleneck.

Have an extra column in the target table that identifies the run (or the run date) when the row was inserted. Use this to identify the rows inserted by a particular run.

Have you checked the "have reviewed this step" box?
ProfileStage does not permit you to advance to the next step until you have told it that you've reviewed the results of the prior step.

SetNull() in Transformer stage, makeNull() in Modify stage, or something like SELECT CASE WHEN 1 = 0 THEN 0 ELSE NULL END FROM DUAL in user-defined SQL in a database stage.

You will need Integer of some kind for the result of Index().

If you back out the changes do things run successfully? If so, the culprit is obvious.

Welcome aboard. :D It has nothing to do with multiple key columns. Even with a single key column a hashed file can not have a duplicate. This is how hashed files work. Any write with an existing key value (single or multiple column) is a destructive overwrite. Some folks leverage this to make the ha...

Ans = Trim(UnixOutput,@FM)

Index should be fine. What are the data types of stage variables? You will need Integer of some kind for the result of Index().

Do you get clean data if you use SOAP ?

Hashed files (including Repository tables might be backed up in corrupted form. They can change shape while the backup is processing through them - for operating system backup utilities that don't "understand" this. The uvbackup utility honours locks on the hashed files.

dvpawankumar wrote:Send the Deatailed solution for Converting Source Date format "MMDDYY "to "YYMMDD".

OK, I've sent it. But I'm not telling you where.