Can you determine which one record isn't making it? Create a relationship from ESS to destination and omit where there's a matching destination record? Or export both lists to excel and check them against each other using a vlookup?
This is, I think, the prime suspect
The 3 match fields for a valid composite key in the source table (no duplicates exist).
... but if you could identify the record that's not making it, I believe the reason will be easier to spot.
I am unable to identify the errant record.
Using the composite key:
Every record in source has a match in destination after run.
Every record in destination has a match in source after run.
If that's true, then our "prime suspect" isn't true.
What is your 3 match fields ? all text ?
Create relation between old and new tables, then
in new table will show "duplicated match" records.
I probably missed something since english is not my native language but this statement sounds wrong to me because :
In a import step, when there are many matching fields, if only one of those is matching the record IS updated, and thus, not created.
So in other words, i think you cannot expect any valid composite key based on multiple fields with import step. You need to create a calculated key which concatenate the three field. Then, use it as the only matching field on your import step.
coherentkris a écrit:
The 3 match fields form a valid composite key in the source table (no duplicates exist).
Seems as if my analysis of the situation was incomplete.
I had forgotten a critical fact in ESS relationships and relationships in general.
Error 1 - the composite key on the source (ESS) side used a calculation (FM / Unstored) field as a match field.
Error 2 (once error 1 was fixed) - The relationship between source and destination using the composite key was one to many.
Fix - null the destination table before import and add new records on import.