Converting Person Information to suit Ancestry Unsupported Fields
Thanks All.
I've recently had a bunch of issues where information to and from ancestry gets lost in translation.
In ancestry we oly have 3 Name fields to play with, Given, Surname and Suffix. and the e.g. Prefix field used in RM doesn't show in Ancestry.
That's not too hard, write a sql script to put the prefix in front of the Given Name. Then just clear all entries of the Prefix in RM, However often times its hidden in a specific Fact, and that Fact needs to be moved to the Prefix, Suffix or Nick Name Field, before running the script.
When the Suffix is already populated by Post Nominals, for example e.g.
Prefix Sir | Given John | Surname Smith | Suffix OAM and then there are facts such as Nickname, Title of Nobility, AKA, AlternateName. that exist as Facts. and each one is an individual fact. there are also often duplicates, and some useless information in these from bad data
Has anyone created a script to move these around so they can be seen in ancestry in the Name. e.g. Sir John "Jack" | Smith | OAM, Lord of Bradford, Lord Bradford.
I'm also looking at trying to fix all those "of that Ilk" records, and to replace all the XIIIth, XIII, 13th, Thirteenth texts in titles to a common standard, e.g. 13th
Will a View (permanent) created in SQLite impact the running of RM?
"Will a View (permanent) created in SQLite impact the running of RM?"
It's hard to imagine any damage that would actually cause. However, it would surely render your database to be "out of support" in the event that you needed to submit your database to RM for analysis. If RM saw the permanent views in your database, they would refuse to help you no matter how clearly unrelated your views were to the problem at hand.
I have a history of using a lot of views, but I have always used temporary views, just out of an abundance of caution. I have needed to submit my database to RM quite a few times, not for them to help me so much as for me to provide them with a database that demonstrates a repeatable bug for them.
Despite my extensive history of using temporary views, I have gradually switched over mostly to using lots of subqueries instead. Subqueries are just as easy to write and debug as views, and they seem to run much faster than views.
Despite my extensive history of using temporary views, I have gradually switched over mostly to using lots of subqueries instead. Subqueries are just as easy to write and debug as views, and they seem to run much faster than views.
Interesting I suppose in theory one would expect negligible difference -- but that is usually not the case in the real world of course.
I'm not worried about support from RM, I tend to be a bit independent, understanding the time it takes to get things fixed, if ever.
FTM have just given up when I get sync issues 🙂
Im finding a lot of issue because the database appears to be a very old version of SQLite, so things aren't supported.
Im finding a lot of issue because the database appears to be a very old version of SQLite, so things aren't supported
not sure I am best person on this -- what do you mean?
Sqlite is diff than SQL or mySql, also it may in part be related to the tool you are using. Some tools allow for some other features. Have you checked the Richard Otter site also?