I’m still using the Free version of the latest RootsMagic9.
I noticed that I had made a spelling error in the Place field in the Marriage Fact for my entry. I had input REgistry Office.
So I click on the Marriage line and in the right hand screen I go to Place and I correct the error and click the big tick at the top. It immediately undoes my correction!
So I go to the other person - my wife and do the same, with the same result.
Curiously, I can amend the end characters of the Place field entry and it saves OK. Also I can remove the whole word REgistry and it saves OK. But when I go in and add the word Registry at the beginning it changes to REgistry on saving.
Very odd.
Just thought I’d add this:
I went into the Place entry in the Marriage Fact and completely removed the text and clicked the Save tick. That worked OK. No entry there at all now. I then closed RootsMagic9 (without creating a Backup).
I then reopened the program and went to the same place - the blank entry was still there. So I typed in Registry Office, clicked the Save tick and REgistry Office appears!
Please note I’m not selecting the dropdown entry (spelt wrongly) that appears when I start typing.
Your scenario sounds impossible. In all my decades of using RM software, I have never seen anything like this happen. But just because your scenario seems impossible doesn’t necessarily mean that it actually is impossible.
I can’t picture a set of steps that a user could do that would make this sort of thing happen. So if it happened to me, what I would do would be to go the the Place list (Globe icon on the left side of the screen) and look at your place there. You may have something weird like your place is in the place list twice, once as Registry and once as REgistry or something like that.
You should be able to make any corrections there. If so, then the corrections will show up correctly on your Marriage facts. If you have two Place entries that are identical except that one of them contains Registry and the other contains REgistry, then merging them would solve the problem. But if there is only one, just fix it in the Place list and it will be fixed everywhere.
In general, if you have this kind of error for several facts, then fixing it for one of the facts will not fix it for all the facts. It will only fix it for one fact at a time. That’s part of the reason that it can be a good idea to look at the Place list. The other reason is that even if you fix this kind of error for all of the facts, the erroneous place will still be in the Place list as an unused item and it would be very easy to use it by accident. So fixing it in the Place list and merging any duplicate items in the Place list is the best overall strategy.
These must have been created as I played around trying to investigate the problem.
So I amended the second one down to read Registry Office, Bangor Castle then saved it and it has automatically fixed the problem in the Place field in my own and my wife’s entries. I didn’t even delete those other odd entries but I will now.
Thanks for that hint. I might try to replicate this problem when I get the time - it may be a bug.
Make sure the entries you are deleting are not being used. I usually find it easier and safer just to merge the entries. Keep the one that’s spelled correctly and merge all the others into it.
Jerry–I went in and tried exactly what @JohnB47 said and he is 100 % correct–you can’t correct spelling etc on the individual fact in some instances–just in the Places on the left as you have said
original
changed
hit save or just click on the the fact and back to the originally
So I opened a 2nd database and the same thing happened UNTIL I changed the info in the fact and then just hit close on the person edit screen–when I went back in the info was changed and I have no problem know changing the info in any fact ( can hit save or the fact etc)–
BUT I can’t on the 1st database on this particular fact–simple weird
Thanks for investigating and confirming this nkess.
Certainly curious behaviour.
It may be something to do with the action associated with the Save tick.
I’ve now merged as per your suggestion thejerrybryan. Thanks.
To add:
I’ve just tried this out again myself. I chose another married couple in the same Tree, added LOndon to the Place field in the marriage fact of one of them and saved. Now I can’t correct that to London - it keeps resetting the entry to LOndon.
Looking in Places I see an entry for LOndon, no other similar. I changed it there to London and that fixed the problem automatically for the Place entry I had made.
Is this a bug that I should somehow flag up - how to do that?
I was thinking a little more about how this might have happened. When you are typing place names into a fact, RM will fill in place names for you from your current place list as sort of a suggestion. You can accept the suggestion are not.
The suggestions are based on the letters you are typing in matching a name in the existing place list. So if I type in Tenn and if I have Tennessee in my existing place list, then the RM is going to suggest Tennessee. But the matching is not case sensitive. So if I have TEnnessee in my existing place list by accident and if I type in Tenn, then it is going to suggest TEnnessee rather than Tennessee. It can be very subtle to notice that this is going on.
I’m sure I don’t have every detail of what happened exactly right. For example, if you go back and fix the upper case letter that should be a lower case letter, I think it should accept your correction. But essentially you got tangled up in a suggestion based on an existing place name that was spelled incorrectly in the sense of the first two letters being capitalized and on the fact that the suggestion process is not case sensitive.
Well, I can say for definite that I am not selecting any phrase presented to me in the Place dropdown as I start typing.
I do understand what you mean and I spotted it straight away and was careful to avoid clicking on anything in the dropdown list. I just make the correction and click save or make the correction, press return and then save. My corrected text is clearly showing in the Place field just before I save or press return and save. In both cases the correction is overwritten with the previous misspelt entry.
Correcting it in Places fixes the problem (as per your earlier help). The correction is automatically applied to the marriage fact ‘Place’ entry I made. I don’t have to correct it in Places and then go into the marriage fact and amend it there too.
I can repeat/replicate this behaviour easily and have done so using different people and Place text but always in the same rmtree.
That’s because RM does not detect that your London edit is any different from its LOndon place so it does not create a new place called London and continues to point the event to the LOndon place record. You could type london or any combination of upper and lower case in that letter sequence and the event’s place field will point to the first place record whose name matches, regardless of case.
I go to a new couple and to one of their Marriage facts and click on it. In the right hand pane I enter Carduff in the Place field and save. It saves correctly.
I close that person selection and then reopen it again and go to the same place. I edit the field to read Cardiff and save. It saves correctly. Going to Places (left hand globe icon) I see entries for Carduff and Cardiff. I delete them both (Cardiff is not used as a place anywhere in my tree so that’s not a problem).
Now I repeat the above process but I incorrectly enter the Place as CArdiff and save. I then go out and back in and try to correct the name to Cardiff - it won’t accept it and always changes it back to CArdiff immediately after clicking on the save tick. Going to the Globe icon again I see only CArdiff as an entry.
So your explanation doesn’t hold true because I can correct an entry but not, it seems, if the incorrect entry contains two capitals at the beginning.
Sounds like it corresponds exactly to the explanations by Jerry and myself but I have not tested to replicate nor am I sure that I understand Nancy’s point. My experience is mainly from RM7; while RM9 shares the same database structure for places and events, the UI is much quirkier.
OK TomH, I can see we aren’t going to agree on this.
It’s clear to me that Nancy (is that nkess?) and myself have demonstrated the exact opposite of what thejerrybryan and yourself are saying.
Jerry suggests, very reasonably, that I’m inadvertently selecting an entry in the Place dropdown as I type in my correction. I’m not doing that.
You suggest that “You could type london or any combination of upper and lower case in that letter sequence and the event’s place field will point to the first place record whose name matches, regardless of case.”
Not so, as demonstrated in my last post. I can successfully change an entry of Carduff to Cardiff but I can’t change an entry of CArdiff to Cardiff.
Anyway, let’s not fall out over it. I just though I’d flag it up because it doesn’t seem correct behaviour to me. If a database allows me to edit a field, then that edited field should be saveable. If it’s not saveable, the code should prevent me from editing the field.
Exactly behaving according to the explanation given by Jerry and myself. Cardiff, cardiff, carDIFF all match case-insensitively to the existing Place name CArdiff and, on clicking the checkmark, the edit field is refreshed by reloading the name from the Place record. RM ignores edits of the Place field that are purely changes in CaSe in order to make selection of a Place from the drop-down list of existing place names faster.
In my 15 years of living with RM, this is the first time that I think anyone has complained about that behaviour.
One other variable in this discussion has not been mentioned - the OS - Jerry and I are on RM9 for Windows. That’s in case we have yet to understand the behaviour you have been describing.
I can confirm that Tom’s summary is accurate for RM9 on macos. The only way to change the case of a saved Place is from the Place Menu. When in the Edit Person screen, changes to the case of an existing place get overwritten with the save action, regardless of whether that change is fixing a case issue or introducing a new case issue.
Ok fair enough. Thanks kevinm. That’s the way it’s been designed.
It wasn’t initially clear to me exactly what was happening, because the behaviour seemed so arbitrary.
However, in my humble opinion the average user would find this behaviour confusing, as I did.
I think it is not best practice to allow a user to amend a fields content, whilst offering a choice of entries in a dropdown list, only to find that sometimes, for no reason that is apparent, their edit is discarded in favour of the original field entry.
I feel that the code handling this field should either not allow the user to edit the content directly and instead point them towards the Place Menu (using a message box) or the code should be designed to handle all kinds of edit to the field content, not just some, in what appears to be a random way.
It’s not a big deal of course and nothing to get all heated up about.
I think RM9 is a very good product and I’m sure I’ll have a great time using it.
It’s important to remember that RM’s facts never actually include place names. What they always include instead is a link to an entry in the place table. However and for good reason, RM partially hides this design from the user in the user interface. For example, if you are entering a fact with a place name which is totally new to your RM database, you do not have to go first to the place table and add the place name, and only then can you add the place name to your new fact by linking to the place table. Instead, you simply type the new place name into the fact. Then RM creates a new entry for you in the place table and then links your new fact to that new place name.
On the other hand, RM doesn’t totally hide this design from the user in the user interface. For example, you can go to the place table and correct the spelling or case of a place name. The spelling or case will then be corrected for all the facts that reference the place name. That’s a good thing. But if your RM database is linked to an Ancestry tree, then the change to the place name will not be reflected from RM up to Ancestry, which may or may not be a good thing. The initial release of TreeShare did reflect such a change in a place name up to Ancestry. But the feature had to be turned off because it meant that the user had to approve the reflection of the change to Ancestry for each each separate fact using the place name.
As a historical note (the history of RM and its predecessors, that is), there was a time when you could make a change to a place name in a fact and that change would change the entry in the place table. That would thereby change the place name for every fact in the database that was already using the fact. I suppose that sounds pretty neat, but it could easily cause completely disastrous results. As a results of complaints from users, RM was changed so that such global changes could only be made from the place list itself. So now if you make a change to a place name in a fact, it makes a new entry in the place table for the new place name and leaves the existing entry in the place table unchanged. I think the new design is a much better design and I would never want to go back to the old design in this regard.
I mention these kinds of issues only to suggest that the design of having the place names separate from the facts on the one hand and making the facts each look like they have their own place name on the other and is trickier than it sounds. It can be very user friendly, as in being able to geocode a place just once and being able to correct the spelling of a place name just once. But then there are all these little gochas.
I’m just thinking out loud and I don’t know for sure, but I wonder if RM’s users might be better served if the tool to suggest place names based on the places names that are already in the place table were case sensitive rather than being case insensitive. It seems to me that all the problems being discussed in this particular thread are being caused by the place name suggestion tool being case insensitive. If the tool were case sensitive, then perhaps there could be a search for duplicate place names that is case insensitive so that place names that differ only in case could be merged.
I climbed the learning curve you describe – I thought I was correcting misspellings in place names by updating the place name in the fact, only to find out a few years later that I had created new entries and had to make edits from the Place Menu to fix misspelling issues.
As @JohnB47 said it wasn’t a big deal once I understood how it worked. I knew about the changes to Treeshare based on user feedback but was not aware of the background to this particular issue. Thanks for that, Jerry. Another good example of ‘be careful what you ask for’.
