DSXchange

Ah. Had you revealed that these were set in the original question it would have saved some time. Congratulations on finding the solution.

Can you please share your configuration file?

In the stage properties there's a number of folders. Click on any one of those and the Available Options to Add frame is populated. One of those folders relates to Record level properties.

It's not a metadata port - it's a TCP port - and, yes, you do need it to connect to DB2. Provided the xmeta user had been created prior to installing, and provided you supplied its correct password to the installer, that should not be a problem.

Exit status 0 is handled by an OK trigger. Exit status 1 would need to be handled by a Custom trigger. The others can be handled by an Otherwise trigger into a Terminator.

How and when was the xmeta user created? Does it have an expiring password?

Are you using a single-node configuration in DEV but not in TEST?

You might also consider using SUBSTRING in the extraction SQL.

Column Import stage can work with metadata that describe a fixed-width structure.

In the Transformer stage use Left() and Right() functions or - to pre-empt the other "experts" - substringing.

Can you please post details from all Peek entries in the job log?

How do you know that the second run updated 0 records?

What were the row counts on each link on the second run?

Does the Transformer stage have a constraint expression? Was it the same source file on both runs?

How about emailing Tony? After all, he's the product manager.

Or maybe Tony will drift by here sometime soon.

I agree about the lack of documentation for this stage type, which I too found after installing Fix Pack 1.

Checksum will not necessarily give you a unique number. There is a small possibility that two values will generate the same checksum value - small enough that most people accept the risk when using the checksum as a comparison technique, its intended purpose.

You don't need anything more. You have to inspect the data you're sending - you are attempting to insert a record that violates the unique constraint implemented by the index named in the error message.

Depends on your Array Size and Transaction Size settings. All of the rows in a committed array will get into the database even if the job aborts (because the COMMIT is sent before the job aborts). Once a COMMIT has been sent, rollback is not available - standard database practice.

Could it be that svAppointDt contains 00000000 (which is not a valid date)?