Jump to content


Photo

A real must for me, please


  • Please log in to reply
15 replies to this topic

#1 bob.s

bob.s

    New Member

  • Members
  • Pip
  • 3 posts

Posted 08 December 2011 - 06:31 AM

I am trying to find my way around my new RootsMagic program and make it work in the best way possible for me.

It seems to me that Master Source Lists and Source Templates only work at the “File” level when I would have expected them to actually work at the Program level.

My specific problem is this. As you will appreciate, the majority of the Source Types listed are biased towards the USA and, frankly, I do not like the actual description of any of them for my purposes. For convenience, I maintain several separate family databases to cater for my wife’s family and my own extended family branches separated into UK, US and Australian files. I maintain about 6 separate folders to make the job more easily manageable.

In regard to sources, I would like to cite, for example:

Certificate of Birth (own)
Certificate of Birth (other)
and similar for marriage and death certificates
GRO Index of Births
and similar for marriages and deaths
UK Census 1911
and similar for all previous censuses

But, unless I am missing something, it seems to me that I have to set up the complete list of sources as a new “Master Source List for each individual folder. I have tried copying and editing templates under Source Templates and assumed that that would update the program’s Master Source List which could then be used to add to the source list for each file, but that doesn’t seem to work.

Am I missing something here? If not, I think that not being able to add to or amend the Master Source List at the program level is a major omission.

#2 Alfred

Alfred

    Advanced Member

  • Members
  • PipPipPip
  • 5734 posts

Posted 08 December 2011 - 09:47 AM

You could create these sources in a master database with no people in it.
Backup this database as MASTER or something.
Restore MASTER each time you start a new family database and rename it appropriately.

OR, you could create an individual in one of your existing databases and cite each of your preferred sources to this individual.
Drag and drop him to each of your other database and then delete him there, the sources will remain.
Alfred

#3 Romer

Romer

    Advanced Member

  • Members
  • PipPipPip
  • 2064 posts

Posted 08 December 2011 - 10:47 AM

Perhaps the reason that source templates are at the file level is to avoid having those that are created above and beyond the system defaults and that might never be used appear and potentially clutter up, say, the file of another user (family member, library patron, etc.) using the program.

There are hundreds of templates, so any additional ones might be unwanted by others or confuse them, particularly if they suddenly appear out-of-the-blue. For master sources, having nonrelevant ones and from another user appear in that user's list could be even more difficult to figure out if trying to search for his/her own already used in the database.

#4 Paul Harris

Paul Harris

    Advanced Member

  • Members
  • PipPipPip
  • 170 posts

Posted 08 December 2011 - 11:43 AM

Perhaps the reason that source templates are at the file level is to avoid having those that are created above and beyond the system defaults and that might never be used appear and potentially clutter up, say, the file of another user (family member, library patron, etc.) using the program.

There are hundreds of templates, so any additional ones might be unwanted by others or confuse them, particularly if they suddenly appear out-of-the-blue. For master sources, having nonrelevant ones and from another user appear in that user's list could be even more difficult to figure out if trying to search for his/her own already used in the database.


I have to sympathize with Bob.S. I believe that this is just another indication that the Source Templates LIST needs to evolve into a Source Templates MANAGER. Templates need to be grouped by their source, especially if they are designed by the user. The user should be able to designate what Groups should be defaults at the program level.

Paul

#5 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6218 posts

Posted 08 December 2011 - 03:53 PM

What do you visualise by "grouping templates by source"? Romer and I developed SQLite queries that show what sources use which template, which would be "grouping sources by template" - a feature that would be helpful in RM in selecting a template for a new source. RM could readily show which templates in the list were in use, by how many sources or even citations, and sort accordingly.
I'm sure there are pros and cons to custom templates per database vs custom templates per program. "By database" does present the challenge in maintaining multiple databases that Bob is confronted with - one solution is to combine them all and use Named Groups to isolate working and reporting. "By program" raises questions about the proliferation of templates if you are exchanging databases with others.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#6 Paul Harris

Paul Harris

    Advanced Member

  • Members
  • PipPipPip
  • 170 posts

Posted 08 December 2011 - 06:32 PM

Tom,

I was referring to the source of the templates, rather than sources, per se. IOW, Mills Evidence, Mills Evidence Explained, Lackey, or my own. Showing 'usage' as you suggest might be very useful.

Paul

#7 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6218 posts

Posted 08 December 2011 - 10:26 PM

Maybe this 'cheat sheet' could help: http://sqlitetoolsfo...lates+by+Origin.
As you will see, the basic query is not so difficult, but the group of templates
originating from Evidence Explained comprises 331. I don't think that makes the
job of template selection a whole lot easier :unsure:

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#8 Paul Harris

Paul Harris

    Advanced Member

  • Members
  • PipPipPip
  • 170 posts

Posted 08 December 2011 - 10:36 PM

... but the group of templates originating from Evidence Explained comprises 331. I don't think that makes the
job of template selection a whole lot easier :unsure:


When complexity overwhelms, divide and conquer, as in http://4.bp.blogspot...dy-Template.jpg

Just like the book, pick from one of twelve main Source Groups, then select from a contextual list of Categories, from which you can select within a contextual list of Templates. There are ways to make things easier.

Paul

#9 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6218 posts

Posted 08 December 2011 - 10:44 PM

Just like the book, pick from one of twelve main Source Groups, then select from a contextual list of Categories, from which you can select within a contextual list of Templates. There are ways to make things easier.

That makes some sense but will require a redesign of the SourceTemplateTable because its Category field is just a cryptic citation with no consistent structure.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#10 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3534 posts

Posted 09 December 2011 - 09:12 AM

It seems to me that Master Source Lists and Source Templates only work at the “File” level when I would have expected them to actually work at the Program level.

There are other data elements that work the same way. For example, fact table entries and associated Sentence Templates only work at the "file" level. There have been wishes for years that there was an easier or better way to share this kind of data between "files". Well, RM would call the files "databases".

GEDCOM is ill suited for transferring this kind of data, especially when the data in question might not be associated with any particular person or fact that is being placed into the GEDCOM that is being created. I have wondered if one approach might be to be able to export and import such data. One wish I submitted a very long time ago was to be able to export and import what I called Style Libraries, which were really just sets of Fact definitions and their associated Sentence Templates. The idea at the time was that one person might develop a truly wonderful and alternative set of sentence templates and "export" them to me. As a part of this wish was the idea that any one particular RM database might be able to store and use multiple Style Libraries, and that you could choose a Style Library at the time you were producing a report. So for one purpose you might produce a report using one Style Library (set of Sentence Templates), and for another purpose you might produce basically the exact same report except using a different Style Library. And a Style Library would deal with all aspects of the Fact Table, not just the Sentence Templates. So one Style Library could have one set of privacy options or options about which facts are included in the report, and another style library could have a different set of privacy options or options about which facts are included in the report.

There are surely other things that could usefully be exported and imported. For example, I could see importing a mature Place List table into an otherwise new and empty database prior to entering any people into the database.

These ideas of export and import would be very consistent with the idea of elevating Source and Citation lists and Source Templates into being a Source Manager, of elevating the Fact List and Sentence Templates into being a Fact and Style Library Manager, of elevating the Place List into being a Place Manager, etc. I think it would be a great long term direction.

But alas, we are very limited at the present time in being able to share this kind of data between databases. For years the best suggestion has been to make a dummy database with one dummy person that has all your Facts, your Sentence Templates, your Sources, your Source Templates, and your Places the way you want them, and then to use a copy of this dummy database anytime you want to start a new database. I think such a dummy database that's comprehensive in all the data that its storing for you is a lot of work to create. I have sometimes wished I could make a copy of my main production database and then delete all the people from said copy with one or two clicks and to delete all the people in such a way that all my facts and templates and lists of various kinds would remain in place. Then I would have a pretty good dummy database with which to start a new database.

Jerry

#11 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6218 posts

Posted 09 December 2011 - 10:45 AM

I have sometimes wished I could make a copy of my main production database and then delete all the people from said copy with one or two clicks and to delete all the people in such a way that all my facts and templates and lists of various kinds would remain in place. Then I would have a pretty good dummy database with which to start a new database.

Jerry, I just did that with SQLite on RM4. It's so trivial that Bruce could easily add it as a menu item under Files > Database tools. All my Custom Facts, Roles, Source Templates, Master Sources, Places, Repositories and Addresses are still in it. With a bit more complexity, media for Places and Master Sources could also be preserved.

I had to go through gyrations that result in my new RM4 Master database not using RMNOCASE. I suspect that a dataset with names using only the English alphabet would work just fine in this database with my NOCASE substitution. It also opened OK in RM5 with NOCASE still in effect everywhere except for a couple of columns in the MultiMediaTable. I'll write up the procedure if anyone is interested...

That would not be the case for Bruce within the program - the RMNOCASE indexes would remain in effect.

So, Bruce, it's really easy to add this feature because it is just a series of DELETEs on selected tables in a copy of the current database appropriately renamed and vacuumed:

File > Make empty Master from current database
Preserve: (checkboxes defaulted to all)
  • Custom Fact Types
  • Custom Source Templates
  • - Master Sources
  • -- Media
  • -- Repositories
  • Places
  • - Media
  • - Place Details
  • -- Media
  • Addresses

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#12 Romer

Romer

    Advanced Member

  • Members
  • PipPipPip
  • 2064 posts

Posted 09 December 2011 - 11:55 AM

There's also another way to narrow the scope of template choice down at least a bit when on-the-fly. In the Add New Source screen, type in the relevant name of the fact (birth, death, etc.), and the list is filtered down accordingly. I just wish that Ref field were also searched, so that you could enter search terms such as "[EE," (without the comma) to bring that element also into consideration. (A separate filter button for Ref might instead be appropriate so that you could use both criteria.)

Remember, too, the Favorites feature to mark those templates that you use. Most probably don't use a huge number of templates in their database.

#13 bob.s

bob.s

    New Member

  • Members
  • Pip
  • 3 posts

Posted 10 December 2011 - 09:14 AM

You could create these sources in a master database with no people in it.
Backup this database as MASTER or something.
Restore MASTER each time you start a new family database and rename it appropriately.

OR, you could create an individual in one of your existing databases and cite each of your preferred sources to this individual.
Drag and drop him to each of your other database and then delete him there, the sources will remain.


Wow! I seem to have stirred up a lot of debate with my simple observation. I'm afraid that as a new user, much of it is going straight over my head, but I wanted to thank you, Alfred, for your practical solution. As I have existing databases, imported through GEDCOM from another package, I tried your second suggestion of creating a "Master" individual with all of my desired sources and dropped him in each database. Success! And saved me much work.

Thanks once again, it just shows that it pays to ask someone who knows their way around!

#14 leeirons

leeirons

    Advanced Member

  • Members
  • PipPipPip
  • 72 posts

Posted 12 December 2011 - 01:36 PM

Glad bob.s found a near-term workaround in order to start using the software. However, considering this is a wish list forum, and not a workaround forum, I think the wish here could be summed up to be what Jerry said would meet the initial need that bob.s indicated: the ability to create a Style file by exporting user defined sources, facts, etc., which could then be imported into any other existing RM data file. The user should be able to set the drive location of a Styles folder, which effectively becomes the library for any number of Styles files the user creates or gets from other users. The xport and import of a Styles file should be enables from each Master window (master sources, master facts, etc.).

#15 ritekgirl

ritekgirl

    Member

  • Members
  • PipPip
  • 8 posts

Posted 23 January 2012 - 09:48 PM

Jerry, I just did that with SQLite on RM4. It's so trivial that Bruce could easily add it as a menu item under Files > Database tools. All my Custom Facts, Roles, Source Templates, Master Sources, Places, Repositories and Addresses are still in it. With a bit more complexity, media for Places and Master Sources could also be preserved. .....


Thanks for this information. It has peeved me no end that when I spend a lot of time creating a new custom fact in one database - that I have to manually create it again in my other databases, but worst of all is when creating a new database that I can't keep all the Fact/Source/Place lists etc.

It would certainly be ideal to incorporate this into the program.

#16 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8414 posts

Posted 24 January 2012 - 04:08 PM

Confirming enhancement requests are in our tracking system.
Renee
RootsMagic