Tom is probably going to reply with a more complete answer, but I would simply point out that RM's RIN number really can't be changed after it's assigned. Among other reasons, it serves as a key for SQL JOIN operations in RM's underlying SQLite database. RM's RIN numbers can be preserved on a GEDCOM import into a new and empty database, but other than that you have no control over them whatsoever. In a way, this is a very natural design. Many different RM tables can be JOIN'ed by the RIN number. But on the other hand, you might wish that the key that's used for such JOIN's might be some secret and invisible key that you never see as a user so that the RIN number could be a number that you could edit. The two options for a numbering system that you can control in RM are the Reference Number fact and the possibility of adding your own fact type for a numbering system. The Reference Number can be made readily visible on a number of RM screens. Your own fact type for a numbering system would be readily visible in the Edit Person window and you can make it visible in People View. Either the Reference Number or your own fact type for a numbering system can be used for color coding, for making Named Groups, or for other selection or searching operations. Jerry -----Original Message----- From: LornaMoa via Sent: Wed, September 24, 2014 6:47 PM To: Tom Holden ; tmg-refugees@rootsweb.com Subject: Re: [TMG-REFUGEES] RM SQLite renumber RIN/TMG_ID 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 > *** 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

I probably should have said that the RIN can't be changed except with an SQLite script, and even then you have to be very careful to get all of the occurrences in the different tables because of the JOIN operations. Jerry -----Original Message----- From: Jerry Bryan via Sent: Thu, September 25, 2014 10:06 AM To: tmg-refugees@rootsweb.com Subject: Re: [TMG-REFUGEES] RM SQLite renumber RIN/TMG_ID Tom is probably going to reply with a more complete answer, but I would simply point out that RM's RIN number really can't be changed after it's assigned. Among other reasons, it serves as a key for SQL JOIN operations in RM's underlying SQLite database. RM's RIN numbers can be preserved on a GEDCOM import into a new and empty database, but other than that you have no control over them whatsoever. In a way, this is a very natural design. Many different RM tables can be JOIN'ed by the RIN number. But on the other hand, you might wish that the key that's used for such JOIN's might be some secret and invisible key that you never see as a user so that the RIN number could be a number that you could edit. The two options for a numbering system that you can control in RM are the Reference Number fact and the possibility of adding your own fact type for a numbering system. The Reference Number can be made readily visible on a number of RM screens. Your own fact type for a numbering system would be readily visible in the Edit Person window and you can make it visible in People View. Either the Reference Number or your own fact type for a numbering system can be used for color coding, for making Named Groups, or for other selection or searching operations. Jerry -----Original Message----- From: LornaMoa via Sent: Wed, September 24, 2014 6:47 PM To: Tom Holden ; tmg-refugees@rootsweb.com Subject: Re: [TMG-REFUGEES] RM SQLite renumber RIN/TMG_ID 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 > *** 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 *** 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