Before you went spelunking, did you rerun the group creation criteria to update the group markings to account for any unlinking you did ? Group criteria are not dynamic (continually self-updating). They must be re-run to account for changes since last run.
I suspect that Kevin’s suggestion to rebuild the groups is the solution.
I just now did an import of RM7 into RM9. My Count Trees results matched between the two. I also just now made a new group for the largest tree in the newly imported RM9 database. The group count matched the count from Count Trees. I have many other disconnected trees within this newly imported RM9 database - too many to test them all. But I expect all the counts to match if I generate a group.
As Kevin mentioned, group criteria are not dynamic. RM9 does now supports refreshable groups, but groups you need to make for the Count Trees comparisons are cannot be refreshable. That’s because the criterion of Everyone in highlighted person’s tree is not a refreshable criterion. I’m hoping that what we are seeing is Version 1.0 of Refreshable Trees and that there will be a Version 2.0 of Refreshable Trees that supports a lot more criteria.
No I did not rebuild the sorted list for the branch where I found the rogue. Thanks for pointing that out.
However I did later find him in the list built after the unlink using RM9. So just to be thorough I went back to rebuild the list under RM7 and he is still not there.
The fact that the RM7’s Count Trees shows some 700 more people than the Custom Report of that branch tells me that the Group generation for “everyone in the highlighted person’s tree” is not finding everyone that Count trees finds. That is neither here nor there because it is fixed in the current RM9. I only posted that to warn other 7 hangers-on that this could be flawed.
\s\Rick
As I said above it didn’t.
The Count Trees between RM7 and RM9 is VERY close. It is the difference between what the Group Count and Count Trees shows on RM7. The Group Count and Count Trees counts in RM9 are quite close.
I tend to go deep and wide then deep again with some of these branches looking for the connection. I still believe it has to do with that. The down/down/over/up/up process or something similar that defeats the RM7 ‘Everyone in …’?
Hmm, I wonder, should I now begin to worry about this difference in counts?? Probably not as when I move to 9 or 10 I will just import the previous database and it seems to clean up the difference in counts as the counts now nearly in sync in RM9 and also close to the RM7 Count Trees count.
\s\Rick