RE: Replication with DB2 and DISTINCT Daniel W Heichel 13.Nov.15 08:43 AM Lotus Notes LEI All ReleasesAll Platforms
Replication has a few more considerations than Direct Transfer. While Replication is more powerful at what it does, sometimes Direct Transfer can be a better fit for "non-standard" requirements, because of its raw simplicity.
Replication will need to build two data sets, one source and one target, that it holds in memory and then runs its comparisons against - one-to-one down the list, record to record. That can sometimes limit our select options on the data. For example, you wouldn't have been able to use a JOIN, because we need to work with one data source on each side. (You can get around that by using a View that joins 2+ tables together, but you could only use that on the Source side of one-way (keyed) Replication - because you cannot write to Views). So depending on what you actually need to do, you might be able to use views. (Or you could use a dependant activity chain that starts with a separate activity, that assembles the data in a "staging area", as you've done.)
DISTINCT is an interesting case. On one hand, all it does is to narrow the range of results you get from a table, and ostensibly that is exactly what the Replication Activity Document's "Conditional Clause for Source/Target" fields are for. However, it seems that it would break the record model we need to work with - comparing unique records and synchronizing them. DISTINCT specifically returns unique column values, not records. If multiple records had the same column value, which of those records gets returned? Are a 1-to-1 compatible list of records returned from both sides of the connection, and in the same order? That's providing that it's compatible with the Replication activity model at all, since DISTINCT is mostly intended to return individual fields, and not entire rows.
Given these concerns, and especially if you have a Direct Transfer example running, that would probably be your best bet.