Thanks Tom >>So you cannot combine two TMG projects with overlapping TMG IDs in a common RootsMagic database and have all the RINs match all the TMG_IDs. I wonder if you can even do that in TMG. To keep common RINs, yet keep the persons separate, they must be in separate databases. << Fully understood. And yes, TMG-IDs are unique within a database but there's nothing stopping us in TMG from using the same id in another database should we wish too. The linked projects I'm talking about are currently in two databases (with some of the individuals having the same id between the two db) because the end results required are quite separate and my ingenuity within TMG ran out when trying to keep them only in one AND to show both real parents and DNA "parents". Quite apart from which, many of the dna project participants are of no interest to my personal research, even if they do turn up as dna matches to the One Name Study people. My main database already contains all of my own family research, PLUS two one name studies, and I happily produce the separate One Name Study webpages from my main database using flags and contains 10s of 1000s of people from many years of research. But the dna website was a step too far given I needed (well wanted) to show a tested person both with his actual pedigree and with his DNA lineage. http://dnasurnames.info if you are at all curious. I cheat within the dna database so I can show both sets of "parents" for selected people. The ones I show on the haplogroup charts are the dna haplogroup branch "person", with a "son" being the patriarch of the line associated with the Y/mtdna value, and the "child" being the tested person. The latter two are duplicated in the database but linked using custom two principal tags. In the Lineages aka Surnames section the duplicated people above show up with normal family relationships, and usually a link to where else they are published (linked by TMG-ID and smarts in SSite), eg one name study or my personal family webpages. Yes, a RM Gedcom output to SSite would probably work, but for the above site, as it currently is configured, only if I can control some of the RINs/TMG_IDs, hence my question about whether your utility would also work on one person in isolation to change the RIN as opposed over the whole database. Some year I may well rethink the whole thing, but for now, my energy is directed elsewhere. Lorna Henderson http://lornahen.com On 25/09/2014 1:10 p.m., Tom Holden wrote: > All that this script does is to replace the imported Record Number with the numerical value of the TMG_ID fact. I suppose that you could edit the TMG_ID value or add a TMG_ID fact to a new person and rerun the script and it would change the RIN to match. BUT RIN must be unique and there is no control on the TMG_ID fact to ensure that. > > So you cannot combine two TMG projects with overlapping TMG IDs in a common RootsMagic database and have all the RINs match all the TMG_IDs. I wonder if you can even do that in TMG. To keep common RINs, yet keep the persons separate, they must be in separate databases. > > John Cardinal is developing Second Site to work with RootsMagic extended GEDCOM. Maybe there is a possibility for there to be some mechanism by which SS websites from two RootsMagic databases may be interlinked. > > Another consideration might be an entirely different approach - why two databases? Why two websites? Maybe one database outputting two kinds of websites? Or one website with filters or two ways of looking at people? Maybe your current solution is predicated on the way things work in TMG and Second Site and another solution is more appropriate and even better with different platforms. > > Tom > >> On Sep 24, 2014, at 6:47 PM, LornaMoa <lornamoa@gmail.com> wrote: >> >> A question on the >>Replace the RootsMagic RIN with the TMG_ID number << >> will that work on a specific RIN/TMG_ID? >> With TMG's ability to assign numbers on input, or renumber a person after input, I use this in my separate but connected DNA project so that the people (several 100s) that are in both the DNA project and in my main project (many thousands), have the same id. >> Which means in SecondSite I can create (using the flag event facility) automatic links for interested readers to jump between the two websites (dna/family) >> >> So whereas at a conversion to RM yes your utility would be great, ongoing use / divergance could cause me some issues (currently still well into the future for these two projects at least so I can still use SSite to generate web pages) >> >> Lorna Henderson >> http://LornaHen.com >> >>> On 25/09/14 8:12, LornaMoa wrote: >>>>> - Map the TMG_ID (the person number familiar to you in TMG) to a Reference Number fact for optional display after the name - Replace the RootsMagic RIN with the TMG_ID number << >>> many thanks in general Tom, but for these two in particular >>> Sometimes its the seemingly little things that count most <g> >>> The latter will probably be my preference as I do have some specific Reference field contents I also know and love, eg DNA project ids, family chart references (as well as some overdue cleanup in TMG itself for prior uses of the field) >>> Trying the new import now on my main TMG project but it will be a while, as I'm running the VFI/optimize on it first, so in several hours..... >>> >>> Lorna Henderson >>> http://LornaHen.com >>> >>>> On 25/09/14 2:04, Tom Holden via wrote: >>>> There will never be a substitute for TMG that will recover all the data, >>>> support the same methods of working, provide the same outputs and, for some >>>> TMG users, nothing less can be acceptable. The same has been true in the >>>> opposite direction. There have been, before August's announcement, TMG >>>> refugees to RootsMagic (and I'm sure to other programs) who swear that they >>>> will never go back because of the issues they had with it. For some, an 80% >>>> score on transfer is good enough - others want 99%. Different strokes... >>>> >>>> There is a RootsMagic update imminent that addresses some of the issues >>>> that were known when the first was released and some that have come up >>>> since. >>>> >>>> There will be a crude mapping from Source Surety to the Quality.Information >>>> parameter but, as you know, RM's three indicators are based on Evidence >>>> Explained while TMG's five indicators are different. That sort of >>>> philosophical and structural difference cannot be bridged. >>>> >>>> One of the virtues of RootsMagic is its readily accessible database. I have >>>> been developing SQLite queries that can be run against it post-import to >>>> affect some things not handled by the import. They demonstrate what benefit >>>> (or complication) might be achieved were a similar process incorporated in >>>> the import while leaving it to the user to decide which outcome is better. >>>> Currently available are: >>>> - Help finding sentences and notes having extant TMG variables and >>>> formatting codes >>>> - Support for split Citation Detail >>>> - Map the TMG_ID (the person number familiar to you in TMG) to a Reference >>>> Number fact for optional display after the name >>>> - Replace the RootsMagic RIN with the TMG_ID number >>>> Coming, I think, will be: >>>> - Help finding sentences for individual events that contain variables for >>>> couple events, e.g., [spouse] >>>> - Add [PlaceDetails] variable to sentences constructed from TMG [L] variable >>>> - Modify [Date] variable to [Date:Plain] in sentence templates if a leading >>>> preposition is detected >>>> >>>> Developed queries can be found via this link: >>>> http://sqlitetoolsforrootsmagic.wikispaces.com/space/content?tag=TMG >>>> >>>> Tom >>>> >>>>> On Sun, Sep 21, 2014 at 8:13 PM, Don Ferguson <don@ferguson.name> wrote: >>>>> >>>>> ... >>>>> >>>>> Nobody else seems to have noticed that the import process makes no attempt >>>>> to handle Citation Sureties, even though some sort of mapping to RM 'Proof' >>>>> should have been possible? OK, it only has 3 categories, but they could at >>>>> least try.... >>>>> >>>>> As far as I'm concerned, the current RM sentence import process creates so >>>>> much rubbish and drops so much detail that it is totally unusable. And even >>>>> if they fixed that (a major task) I still see RM's poor media handling, >>>>> dreadful charting and reports, lack of Flags as total show-stoppers - it >>>>> will never be a viable transfer product for me without major development. >>>> *** >>>> To unsubscribe from the list, please send an email to TMG-REFUGEES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the message subject and body. >>>> ------------------------------- >>>> To unsubscribe from the list, please send an email to TMG-REFUGEES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message