DSXchange

I think smalldatetime is the datetime within a restricted period.

You need to supply the default timestamp format.

Check whether the column is a timestamp and also whether you are doing a cast in it.

First-of-all, why are you specific about merge?

You can achieve your requirement by using an outer join in merge followed by constraints in transformer.

There are many combinations and options. The solution will be specific to each customer.

In this case, are you asking for professional services?

There are limitations in any software or tool. Any limitation can be counteracted by alternative means such as knowledge in other software linked to DataStage.

Can you provide more information as to what you are looking for and why.

I agree with keftos. If you want to update change to even one column, you may be better-off performing 'insert new or update existing rows' or vice-versa as that will give you the flexibility to track any change in any column.

Check for the file size (>= 2Gb).

Also check whether you have any stages / process following the one writing to a sequential file.

What happens when it hangs? Does the row count increase at a slow rate or does it completly stall?

Did you check the seq file in these cases?

Did you check whether you are receiving any warning?

Also can you constraint the output so it will not write anything. This will give you the read performance.

Do you do any lookups in the job?

You can write the rejected rows in a separate file and manually verify their occurance in the hash file.

Also check the constraint logic to reject the rows.

Your error appears to do with operating system permissions to create the hash file.

You may probably be using a script to move the hash-files around.

Also check whether you use any parameter(s) embedded in the hash-file names and ensure that the values are passed correctly.

If all you want is a few rows in the file, you can generate yourself using the transformer and a stage variable and make it to write them out in any file you want.

You can pass your SSN to EmpName to match them during testing.

There can be several reasons for the delay. Some are
1.) network traffic
2.) target db having space problem
3.) source extraction is slow

Does your SAP CRM run on SAP R/3 or SAP BW?

Even then, you can search for that topic as it contains the steps to achieve your requirement.

You may have to decide on which columns you wish to track because finding changes on even one column - especially if it is a varchar - can be tedious and time consuming during execution.

Check the columns used to reference the lookup and ensure that they are the same columns used in the 'where' clause for update.

Are you performing a slowly-changing-dimension?

Search for that topic in the forum for more info.