Report of odd occurrence with place/place details
I am not reporting this to look for help in fixing the issue – I already did that with sqlite.
I believe I correctly identified what happened but I have no idea what caused it or why. I may have split/unsplit a location at time time in a previous version – I suspect that as one possible contributing cause.
this place should not have a masterID (placetype = 0 ) and it turned out placeID = 1600 also had 205 associated with it (see video link). I did run database tools so that did not resolve the issue. The issue may have nothing to do with the current version but result of something that went wrong in a previous version. I do not believe place with PlaceType = 0 should have a non-zero in MasterID – this should occur when PlaceType = 2.(has PlaceDetails).
(Caution advised)
This was not possible to cleanup in RM UI so I used Sqlite (this would need an update query – and not recommended by RM -also you could potentially seriously mess up you place table (along with associated links) if not done correctly.
Here is the link (no audio) – sorry I used the built in windows screen grab instead of Camtasia
RM11 W11 - Place Details issue.mp4
One would typically attribute the existence of MasterID=488, as having originally been a Place Detail belonging to PlaceID=488 (eg. if it was associated with Templeton, Worcester, Massachusetts, United States) and the Place Details Name field having been just Greenlawn Cemetery.
Does the PlaceID=488 stand out or ring a bell or represent some other Worcester County place?
good Question –
No it does not make sense or ring any bells– if it was only one it might make sense. I am sure I may have split or unsplit a few now and then. I show many for others as well.
Select MasterID, Count(PlaceID)
FROM PlaceTable
Where PlaceType = 0 and MasterID <> 0
GROUP By MasterID
Having Count(PlaceID) > 0
some are abbreviations also
adding that 488 is (or was a place detail “Douglas Street” and masterID was 17219
Now 17219 would be city that I have over 100 place details as that is a home to lots of people and events but it also has a masterid 522 (that is for a cemetery location in diff state)
My thoughts were on a tangent of maybe a merge operation gone bad… like selecting two variations of a Place name and maybe selecting the wrong one first (as the target to be kept) followed by the merge into operation (or similar circumstances all in succession).
yes agreed possible explanation for a couple – but not dozens or over 100.
My reason for posting this –is to attempt to figure out root cause for others so the scenario can be avoided or if there is or was a programing issue that needed addressing. I fixed the place with sqlite so I am all set – I suspect several of them have been around for awhile and I just happen to notice them when I was looking for places without GPS info
Kevin
one other thing I found – max date for master ID is from June 2023 (place id 754)
I do not have any place ids over 23,000 but there is this
My assumption about MasterID possibly being associated with PlaceID of parent Place is obviously wrong. In messing around with Places/Place Details, I can see that PlaceType=0 Places DO appear to get assigned MasterID other than 0:
Two Place names as representations of “effectively” the same Place (note MasterID=100, but PlaceID=100 is the built-in "Temple” Place Name for PlaceType=1 Place entries).
1 Like
okay so there seem to be exceptions – I do not use LDS or temple with my databases.
100 (in my db) is for abbreviation type. MONTR - Montreal Quebec so that is interesting.
I’m a Windows user, presently on RM 11.0.4 32-bit. I do not use Place Details.
I tested just now with all my database from RM7 through RM11.
RM7, RM8, and RM9 do not have the problem. RM10 and RM11 do have the problem.
Whatever went wrong, went wrong before RM11. It appears to me that the bad MasterID’s just need to be zeroed out. There is probably something in RM10 and RM11 that is not zeroing them out, whereas the problem was not there until RM10.
I doubt the problem is actually causing any damage because the MasterID field is not meaningful for records that are Master Place records. It’s only meaningful for Place Details records.
no damage maybe not – but there should not be orphan place details one can not access to remove and I never had any place details
In my case at least, there are no orphan Place Details. Indeed, there are no Place Details at all in my database. So if there are no Place Details, there cannot be any orphan Place Details. That is correct since I don’t use Place Details.
What I have instead is an unused field in which I would expect to see a zero and in which there is a non-zero. The unused fields that are not zero are for Places, not for Place Details.
1 Like
Correct makes sense in your case (if that was not true then it would be more concerning )
I am not sure what led to the 205 Place details gremlins for that location but certainly that should not be able to occur. Thanks for digging into your examples – again for me I can fix it –others might not be so lucky if trying to do within RM UI–I doubt that would be possible
I will leave it to the RM team – but here is part of what AI said:
Why is MasterID populated when it shouldn’t be?
If you are seeing non-zero values in MasterID for PlaceType = 0, you are likely looking at one of three things:
-
Legacy Artifacts: The record used to be a Place Detail (Type 2) and was changed to a Place (Type 0), but the cleanup script didn’t “zero out” the MasterID.
-
Pointer Reuse: The software might be using that field for an undocumented purpose (like merging or temporary IDs) when the type is 0.
-
Data Corruption: A bug in the application layer is inserting values into the wrong column index.
