There are appears to be a design flaw not being reset when “Set Relationships”.
I discovered that some people in the PersonTable that (WHERE Relate1 + Relate2 = 0 and Flags > 0) - I had several dozen with flags NOT Zero. It appears that RM does not clear them-- guessing this could be result of when you change relationships and change back something is left behind. I manually cleared them using SQLITE and then did not reappear.
below are the counts for them (the 0 is shown for comparison)
I have not tried to determine what causes it – but it something the user should not be able break.
For example – if they set relationships from their child and switch to the Grandchild and back again – previous set flags should not linger
Thanks, Kevin. This does not appear to be the issue I am having. I am seeing spouses of nieces/nephews and aunts/uncles who do not have a flag set to 2 in the PersonTable. I did set the relationships as described in these posts.
That’s a really interesting question. I would have thought that proper implementation of “Set Relationships” would include first running the “Clear Relationships” functionality. Are you saying that’s not true?
If it isn’t true, then this would seem to be something else that changed post RM7. The popup box on set relations specifically says clearing before it sets them in RM7.
Asking if the outcome of Clear Relationships followed by Set Relationships DID work sounds like a plausible troubleshooting question, which the answer, might be valuable to the developer’s efforts. Just saying.
I tested again only in RM UI – I select a person I knew would not shared all of the same people (But would share a large portion). The way I reset last time was using Sqlite.
relationships set to 20113
Set to 4660 (without clearing)
Then Cleared before setting back to 20113
The handful of people with flags not 0 (also relate1 + relate2 = 0 ) were only related to 4660. here is one of them (no relation to 20113 but has flags). So this actually would be a design flaw as clearing does not work as expected.
Here is sort of a big picture question about this whole thread. If Relate1 and Relate2 are both 0, does that make the value of Flags into a “don’t care” situation?
“don’t care” is a correct technical term for Boolean logic with bits where if certain bits have certain values then the value of other bits don’t matter. They are the “don’t care” bits. So maybe the value of Flags is “don’t care” until either Relate1 or Relate2 become non-zero. And if the value of Flags is set correctly when Relate1 or Relate2 or both become non-zero, then the previous value of Flags may be “don’t care”.
By the way, even if my guess is correct, as a matter of personal programming style, I don’t like to leave data elements in an indeterminate state even during times when their exact values don’t matter.
agreed (of course matter to who) but this leaving things in “wrong state” has led to many other issues when done outside of RM including more serious consequences
I did try to clear the relationships before I re-ran set relationships. I am still getting people who are spouses of blood relatives showing as a relative. For instance, I have a spouses of aunts who are showing as an uncles. If I run a Relationship Chart for spouse of the aunt it returns blank. Using SQLite I can see the Flag in the PersonTable is still set to 0 when it should be set to 6.
The spouse of your aunt is an uncle so this would seen to be reasonable behavior. I also seen to recall in a recent post by @rzamor1 that this wss correct up to a certain point in the line, then this assumption of a relative stopped happening.
my understanding for Immediate Aunts & unlces that is operating by RM design. (I do not agree with)
The error I described and reproduce is “junk” left in the table (on flags). I am not sure how many cases would leave flags that no longer belong but illusrated one. It may be RM position that since they are no longer a relative then there is no need to clear the flag (I also disagree about that). All 3 fields should be cleared (after choosing Clear and then set)
