This kind of challenge/problem/practice/exercise is why I prefer very much to work with people and have someone else check my work. I know that in most cases I can get the expected answer from the provided start if I know what the answer is. If I do not have a specific number that I am expected to get then I can veer off in weird directions.
Learnings -
1. Different questions can require or use significantly different tactics. Here Q1 made good use of an iterative macro, and Q2 only needed a few simple tools.
2. Debugging macros is tricky. In this case I had to use message tools (Developer tab) and turn on macro messages in the main workflow.
3. Iterative macros DO use the iteration number, but I could not change it in the macro for testing purposes. I do not know whether this was the case for everyone.
4. When you use a Join tool then the output report (where you might see errors) will tell you the values of the output anchors (L, J, and R). If the records in the L and J (J and R) output anchors number more than the L (R) input anchor then there is duplication happening in the join. Unless this is intentional you may have an error.
4. This challenge reinforced something that I have learned over a long time. That is the following: Knowing how to understand errors and fix problems in your process is as important as knowing what the process does and how to use it.
