Relationship Set/Clear leave Flags

I recall this being reported before but apparently its not fixed still

Go to"desired" person --Clear Relationship – then go back & set relationship
A person who is 0 relate1 & relate2 with sometimes still have flags-- this is expected to be none. The clear function does not clear for all apparently.

Can it be confirmed that development is still aware of this issue?

When you clear relationships inside RM do you still see relationships there? I’m not referring to viewing outside of RM as your screen shot shows.

I’m not the poster of the question, but I think that the answer is that you can’t see the flags that are still there from inside of RM but you can see them from outside of RM, basically via SQLite using some sort of SQLite based tool.

correct – and they should not be wrong and left behind if there is not longer relationship.
I suspect this happens if when you change the “Set person” (even if you clear relationships)
Example when you change from your to one of children or cousins or similar then change back. The relationships seem to update correctly. But it seems bad design to flags not set to zero when they should be zero.

I’m guessing it’s fastest to clear all the Relate1 and Relate2 column values followed by setting only those that apply to the selected person. Those rows with zeroed values for Relate1 and Relate2 columns do not apply and their Flags can be ignored, so why spend time on additional I/O and UI execution time overwriting them with zeros.

inside of RM – since you can not see the flags inside of RM UI – everything seems correct.
However, it seems bad design to flags not set to zero when they should be zero. (There is no longer a valid relationship ). Obviously, I can run an update query Update/ Set flags = 0 where Relate1 = 0 and Relate2 = 0 (not actual code by intent)

Kevin

they already spent the time change the same rows for the other fields-- one more field in same (row) is not going to matter.

That’s your premise, not the programmers’ who’ve made the choice.

true – but its not good design choice to leave clutter behind. But if one can point to not changing the field to ZERO is good database management I would be interested. The performance difference is likely not measurable so that is not a good argument

.

Your perspective is from someone who “diddles” the data externally. The average RM user knows not what You speak of, nor care.

And besides, there’s always the misconception that every operation the program performs is SQL statement-based. It’s certainly possible that their toolset uses other means of programming, like operations involving specific arrays and index values that act as modular-designed constructs (or whatever), instead of just full-table scans and mass edits.

Telling the programmers they’re doing it wrong might be a bit of a leap. After all, they are not going to explain why they do what they do (to you), instead just asking what does not work (as rzamor1 did).

I was asking if there was justification based on your comment.

That would be something you are assuming – what I do is a bit more than diddles.

well I do not recall saying that – but regardless of the exact method/tool the concept is the same. Some other tools might be more efficient

The more important word is externally.

the bottom line is - you would not (in most cases) leave an inactive phone # in the database even if someone can’t see the inactive phone on the front end UI. (for a different analogy)

I agree with @kbens0n that your question is not relevant to this user group if there is no evidence of an incorrect behaviour via the user interface or if it is not a request for enhancement.

But I also think that his choice of word to describe your accessing and manipulating the data by external means is inappropriate and pejorative.

1 Like

true – not incorrect behavior as result from UI – however there is also not way for the avg user to know this or to be able to correct which was part of my point.

My question to Renee if it was reported to development as it appears it was felt that it did not warrant making development aware of the “issue” (not my place to say it should be fixed – but they definitely should be made aware of).

Of all the crap on the planet to find inappropriate and you pick up on ‘diddles’?

Anyway, I frankly think that RM needs to do one of two things, either get rid of the RMNOCASE proprietary crap so that everyone that wants to can diddle their their heart’s content, or lock down the datafile completely so that noone can diddle it outside of the program.

That database was not designed with the forethought that anyone would chose to diddle it outside of the original UI. Maybe FTM was on to something when they locked their DB down.

Confirming problem was reported earlier. Just want to clarify that I didn’t miss its urgency with it showing inside RM.

I find your comment rather insulting to kevync1985. Let me assure you that he does not “diddles” with the data nor is your usage of “data externally” accurate. In the first place, what he does with the data using SQL increases the effectiveness of Roots Magic by 60%.

The average user should be grateful to users like kevync1985 (and myself) who discover issues that, while not seen directly, can cause issues within the programmer. Programmers like use do not criticize other programmers work (at least those with integrity don’t). When we find these types of issue, are intention is only to bring a potential issue to their attention. Flags in database not resetting correctly can cause unforeseen problems that would be reported as “weird” or “strange”. Ie; “I have this weird issue with my great grand-aunt’s relationship to my cousin”.

One last side note; What, exactly, is the point of your comments? People like you really bother me when you aim critical comments at a person who is seeking answers. If you don’t like what he is doing, then please keep it to yourself.

Diddle:

informal
cheat or swindle (someone) so as to deprive them of something.
“he thought he’d been diddled out of his change”

deliberately falsify (something).
"he diddled his income tax returns"

informal•North American
pass time aimlessly or unproductively.
"why diddle around with slow costly tests?"falsify

I asked AI if using SQL was external to the application

"Standard Application SQL Usage

Typically, applications communicate with databases using SQL as part of their internal operations. The application code:

Connects to a database with proper permissions.

Issues SQL queries (SELECT, INSERT, UPDATE, DELETE) to pull or manipulate data as needed.

In this scenario, SQL is not “external” to the application—it is part of the application’s normal data processing workflow."

Note to Admin
I mean this post to be a polite critique of someone’s post, just as they did with theirs. My intention is only to clear up a few facts in that post which really has no relevance to the original post. Since I work with kevync1985 and have benefited from his work (and knowledge) I found this post troubling. I had several issues when using relationships provide by RM. Using his scripts I have an extraordinary view of all my relationships in the database. I concur that there are issues with the flags not resetting properly and only hope this makes it to the programmers for their review.

1 Like

Thank you - I do not see or have found any reason for urgency – however that said – it is usually good if users notice any strange behavior to be aware – whether there are diddling RM or diddling externally.

1 Like

I’m a bit surprised by the tone of some of these comments. Irrespective of who’s “right” and who’s “wrong” - and that’s well past my pay grade - may I please suggest it would be good to step back and take a breath. The FAQ’s say : This is a civilised place for public discussion, Improve the discussion, Be agreeable, even when you disagree. I think that’s good advice. When we start using words like ‘crap’, ‘insulting’ and saying things like ‘people like you really bother me’ it doesn’t bode well for our Community. C’mon guys, chill out!

4 Likes