Rob van der Heij wrote: > No you're not. You put the unmatched details in a lookup as if they > were masters, and then when the master comes in you also pass a copy > as detail to this stage
--and you're still stuck buffering at least all the unmatched records, and fighting with input 3 of LOOKUP to delete the matched ones. Sure would be convenient to have an AUTODELete keyword like AUTOADD, to delete master records once they're matched rather than having to figure out the right combination of COPY and LOOKUP STRICT to feed them back into input 3 without danger of stalling. In this case there wouldn't be anything on input 2 to worry about, but in the more general case I'm not sure how I would ensure that a matched record was fed back fast enough to avoid deleting a newly added master record that happened to match it. (Oh, and John, check your spelling of "quaternary" in recent updates. Personally, I'd spell it "third alternate" to make it match up more obviously with stream numbers. Then we could also stop worrying about whether "quinary" and "quinternary" actually mean the same thing.) ¬R
