First Experience with TMG Direct ImportTMG Direct Import Issues
Posted 20 November 2014 - 08:40 PM
Jerry, the same issue applies to that yyyy Census conversion.
Posted 20 November 2014 - 09:12 PM
Fortunately for me, I don't use shared facts.
I've looked at the yyyy Census conversion script, but I haven't run it yet. It will probably be some time over the weekend before I have time. It looks very good for my needs.
Posted 20 November 2014 - 10:39 PM
I just read the warning on the script I used, I can go back one backup?
Jerry is starting to convince me that I should have left the Census facts the way they were.
Posted 21 November 2014 - 04:16 PM
I just read the warning on the script I used, I can go back one backup?
I'm guessing you used the script on Facts - Change Fact Type. I just put up the warning last night. I have worked out support for shared events for Fact Type - Convert Census to yyyy Census and back but that is perhaps the easier to do because it creates new fact types from existing. This change fact type script has to merge the role definitions from the subject fact type into its target fact type. That opens up a can of worms when there are roles in both having the same name with different sentence templates...
Posted 22 November 2014 - 01:31 PM
A revised script to support the conversion of shared events to a different fact type has now been posted to Facts - Change Fact Type.
Posted 22 November 2014 - 01:51 PM
Posted 22 November 2014 - 03:41 PM
Hi Tom, (Jerry and others),
I am having problems with the "Shared - Census" fact generating sentences after using your script to compress all my Census facts into one. I do not have the same problem using my backup RM data file where I have a separate census fact for each census.
The background is:
When I migrated from TMG to RM the census facts related to the Principle came across to RM as non shared (e.g. 1891 Census"). The facts related to the associated witnesses (with all roles intact) came across to RM as shared facts (e.g. Shared - 1891 Census (Principle's name)". Prior to using Tom's script, if I create a sentences for a particular role within a particular sentence within the "Census" fact it would work as you expect to work.
When I used Tom's script to compress all Census facts into one Census fact a similar thing happened with the single "Census" (i.e. only displaying as Shared if the fact related to a witness to that fact).
Even though my "Census" fact has all roles and sentences added (and they work beautifully for the Principle) there is not sentence produced when I display a shared Census fact.
Do I need to go back to the backup and start again and not use your script this time or is there a workaround or have I overlooked something?
Did you go to Lists, Fact type lists and edit the Census fact to see if the Sharee roles have sentences?
Wayne's issues arose from his use of the initial script on Facts - Change Fact Type to change his several YYYY-Census fact types to the standard Census fact type. At that time, the script did not properly support shared events. I had overlooked that Role definitions are dependent on the fact type, i.e., the Witness role for one fact type is independent of that for another fact type. While the event continued to be shared, the sentence template controlling the output for the Witness was that of the original fact type, not that of the Witness role in the target Census fact type. Thus, editing the Census Witness role has no effect on the sentence output; one would have to edit the Witness role for the original YYYY-Census fact type to modify the sentence output. That is very confusing and liable to result in unexpected anomalies in the user interface and various outputs. Alternatively, one would have to reassign the Role for that person to the Witness Role of the Census fact type, a laborious undertaking.
I have posted a revised script that respects and preserves the sharers' roles through the change of fact type. It uses an existing role in the target fact type when there is a match and replicates others when there is no match. Hopefully, he can go to a backup before his initial use of Facts - Change Fact Type and, by applying the revised script, achieve what he hoped for.
Posted 22 November 2014 - 06:04 PM
I have now run Tom's script (the unshared fact version in my case), and I couldn't possibly be happier. I did encounter three problems, but in all three cases they were user errors (the user making the error would be me ).
- The first time I ran the script, I didn't wait long enough for it to finish before starting RM. I guess I'm used to running SQLite scripts which are query only, and which run virtually instantaneously. On my database of about 60,000 people, the census update script ran about 20 seconds, and I just didn't wait long enough for it to finish. I therefore got a bunch of error messages suggesting database corruption. So I just restored my database and ran the script again - waiting for it to finish this time. All is well.
- I ended up with about a dozen individuals with census events in very strange non-census years. It turned out to be the case that many years ago I would sometimes use RM's built-in census fact for census like data that wasn't really census data, such as city directory data. I would adjust the individual sentence template for such events to say "City Directory" or whatever instead of census. I no longer do it that way. I create user-defined fact types such as City Directory instead. I thought I had cleaned up all the cases where I had used the census fact type for something else, but obviously I hadn't. I think this is a cautionary tale about the lack of wisdom in storing data in what is really a metadata field - e.g., storing the fact that we are working with a city directory instead of a census in a sentence template rather than storing the data directly in a City Directory event. It turns out that running Tom's script has made it much easier to identify and clean up these problems than would otherwise be the case.
- I ended up with two cases where Tom's script converted a census event to a new fact type whose name was a blank followed by the letters CENSUS. It turned out that before running the script I had two instances of a census fact where there was no date or place. This was obviously some kind of data entry error, like I started to type in a census event but didn't complete the process for some reason. Actually, I suspect that in both cases the census events without a date or place came into my database via GEDCOM import over a decade ago before I quit importing GEDCOM without taking a great deal of care. In any case, running Tom's script has made it much easier to identify and clean up these problems than would otherwise be the case.
I have already started using my new year-specific census events as columns in People View to great effect, and I am very happy with the result. This will allow me to work directly in RM in cases where I used to have to write SQLite scripts to obtain the information I needed.
Posted 21 August 2016 - 08:39 AM
Wow, I'm glad I asked this question. It produced a lot of great information on several issues I have also been having. Thank you everyone for chiming in with your questions and answers. And thank you Tom for the answer to my original question. I'm feeling a little more comfortable about migrating to RM. There are lots of things for me to clean up, but at least now I think it might be possible.
Posted 21 August 2016 - 08:45 AM
Sorry about the last post. Thought I was in a different discussion. But the message remains the same. Feeling more confident.