Jump to content


Photo

Record Numbers & Reference Numbers


  • Please log in to reply
14 replies to this topic

#1 D. Spencer Hines

D. Spencer Hines

    Advanced Member

  • Members
  • PipPipPip
  • 38 posts

Posted 19 May 2014 - 03:23 PM

Are Record Numbers "reassigned" when a user of RM6 makes deletions of individuals in the database and perhaps "holes" develop?  When the user runs Database Tools are all those "holes" filled in with formerly used Record Numbers?

 

Same question for Reference Numbers.

 

How can the user know if the "holes" have indeed been filled in with recycled numbers?

 

D. Spencer Hines

 



#2 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3692 posts

Posted 19 May 2014 - 03:38 PM

In normal operation, RM does not fill holes in record numbers. However, record numbers can be reassigned by a GEDCOM export/import process which will get rid of the holes. And a drag and drop operation is a GEDCOM export/import. GEDCOM import into a new, empty database has an option to retain the old record numbers, including retaining any holes.

 

Reference numbers are not assigned nor reassigned by RM, and therefore RM does not cause any holes to develop nor cause any holes not to develop. Reference numbers are strictly up to you, not up to RM. Indeed, multiple people can have the same reference number and one person can have multiple reference numbers.

 

Jerry



#3 D. Spencer Hines

D. Spencer Hines

    Advanced Member

  • Members
  • PipPipPip
  • 38 posts

Posted 19 May 2014 - 05:18 PM

Many thanks for that crystal-clear response.  Most helpful.

 

Just to make sure I understand the processes:

 

1.  I export a GEDCOM file of my database to some safe venue.

 

2.  I then import that self-same GEDCOM to form a BRAND NEW database in RM6 -- and therefore ostensibly get rid of the holes,

 

3.  Do I have it right?

 

New Subject:

 

Would it be a Good Idea to have a user-directed command in RM6 in order to allow the user to do this internally to RM6?

 

Legacy 8 already has a user-directed command for that.

 

Me ke aloha pumehana,

 

D. Spencer Hines



#4 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6298 posts

Posted 19 May 2014 - 05:42 PM

To look for holes in record numbers, you could include Record Number in People View, sort on that column and inspect. Similarly, for Reference Number. But that kind of inspection could be tedious and hit or miss. Another approach would be a custom report with just the one field and sorted thereon; save as a TXT file, import into Excel or other spreadsheet, add a formula to check that the value in the following cell is consecutive. A SQLite query could readily find gaps.


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.


#5 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3692 posts

Posted 19 May 2014 - 08:00 PM

Just to make sure I understand the processes:

 

1.  I export a GEDCOM file of my database to some safe venue.

 

2.  I then import that self-same GEDCOM to form a BRAND NEW database in RM6 -- and therefore ostensibly get rid of the holes,

 

3.  Do I have it right?

 

 

 

Correct. And be sure not to enable the "keep record number option" on the import.

 

I just double checked and the "keep record number option" only seems to be available on an explicit export/import and does not seem to be availablee on a drag and drop which uses an implicit export/import behind the scenes. (I could have sworn the option was available either way, but I remembered incorrectly). Since you wish to get rid of the holes, either technique will work in your case.

 

Whether you use an explicit export/import or whether you use a drag and drop, double check all your fact types to be sure they are enabled for GEDCOM export. Any fact not so enabled will be lost otherwise. All facts are enabled by default, so they should be fine unless you have gone in to turn some of them off.

 

Jerry



#6 D. Spencer Hines

D. Spencer Hines

    Advanced Member

  • Members
  • PipPipPip
  • 38 posts

Posted 19 May 2014 - 08:41 PM

Replying to both Tom H. and c24m48 [Weird!].

 

Tom H.:

 

Thank you.  Sincerely, I kid you not.  Now, this evening I will jump through three or four hoops and train my dogs and cat to do the same.

 

Build the feature into RM7.  Don't make us jump through hoops to get a clean file.

 

c24m48 [Weird!]:

 

Many thanks. 

 

So, the bottom line is that the GEDCOM I reimport into RM6 may be damaged goods unless I jump through hoops.  Got it!  See answer above to Tom H.

 

Drag and Drop No Good -- I Got That Too.

 

Bottom Line:  Put the ability to ensure there are no holes in the database, with respect to Reference Numbers, IN the program RM6 or RM7 -- as Legacy 8 has ALREADY DONE.

 

D. Spencer Hines



#7 zhangrau

zhangrau

    Advanced Member

  • Members
  • PipPipPip
  • 1550 posts

Posted 20 May 2014 - 06:12 AM

I'm not a database programmer, but I don't see why it's important for the Record Numbers to be continuous. As long as the SQL engine is successful at tracking data, what difference does a "hole" make?



#8 Renee Zamora

Renee Zamora

    Advanced Member

  • Admin
  • PipPipPip
  • 8553 posts

Posted 20 May 2014 - 09:04 AM

I'm not a database programmer, but I don't see why it's important for the Record Numbers to be continuous. As long as the SQL engine is successful at tracking data, what difference does a "hole" make?

 

That is RootsMagic opinion also. It makes no difference if you have gaps in your record numbers. Record numbers are computer generated and have no meaning. We don't recommend that people keep track of the individuals in their databases by record numbers. Use the reference numbers to keep track manually of your record systems. Filing systems based on records numbers will fail over time when people rely on them and then there is a need to GEDCOM or drag n drop because you have some type of corruption in your database. 

 

Filling in  "the holes" make no sense either because that would shuffle any system someone was using to keep track of people too. If you want to know how many people are in your database use File>Properties.  

 

Just because Legacy does it one way and we do it another does not mean either party is correct. It's just an issue of what people are used to and goal of the programmer. Our goal is to not have people dependent on a record number, with no meaning, because over time those fail. 


Renee
RootsMagic

#9 D. Spencer Hines

D. Spencer Hines

    Advanced Member

  • Members
  • PipPipPip
  • 38 posts

Posted 20 May 2014 - 10:26 AM

I beg to differ.

 

Far better to have no holes in the database.  One can then line up all records by their Record Numbers and see precisely what the count is and who has which Record Number -- 1 through 1,000,000 and beyond.  If the numbers get changed later, so be it -- one can still line up the database with no holes and sequential Record Numbers.

 

Eliminate holes in the database.

 

Neat, clean and coherent.  Controlled by commands internal to the program.

 

No messy business of exporting and then reimporting GEDCOM files -- which may lead to reimported GEDCOM files that do not have all the same data in them that was originally in the RootsMagic Database.

 

Legacy 8.0-Family Tree has done precisely that -- and thereby stolen the march on RootsMagic.

 

Quod Erat Demonstrandum.

 

D. Spencer Hines



#10 kbens0n

kbens0n

    Advanced Member

  • Members
  • PipPipPip
  • 3464 posts

Posted 20 May 2014 - 11:24 AM

Please devote the programmers' time to issues other than this. Very few product users will, in practice, ever exercise such a feature.

---
--- "GENEALOGY, n. An account of one's descent from an ancestor who did not particularly care to trace his own." - Ambrose Bierce
--- "The trouble ain't what people don't know, it's what they know that ain't so." - Josh Billings
---Ô¿Ô---
K e V i N


#11 D. Spencer Hines

D. Spencer Hines

    Advanced Member

  • Members
  • PipPipPip
  • 38 posts

Posted 20 May 2014 - 11:59 AM

Here's another curiosity in RootsMagic 6.

 

When I click on File>Properties I see I have 24,048 People in the database and 12,346 Families.

 

However, when I Export a GEDCOM of that same database I see there are only 24,040 People and 12,340 Families.

 

What happened?

 

New But Associated Point:

 

When I run Clean Phantom Records in Database Tools in RM6 why aren't all the holes in the database filled?

 

D. Spencer Hines



#12 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6298 posts

Posted 20 May 2014 - 01:29 PM

While I cannot account for the discrepancies of 8 people and 6 families between the Database Properties report and your GEDCOM export, I am not surprised and can advise that there are many more potential discrepancies. The program report is simply a count of records in each primary table, whether a record is used or not. After deletions and mergings, there can remain a variety of records that are no longer used "phantoms" because RootsMagic is lazy about cleaning up the detritus. Some, but not all, types of phantoms are cleaned up by the Database tool. Places become unused and can be removed from within the Place List manager. But facts may remain for non-existent persons, citations for non-existent persons and facts, likewise for media links and WebTags. It takes an export/import or drag'n'drop to a new database to strip these out.

As to your second question, I think I recall correctly that RootsMagic 3 and earlier and Its predecessor Family Origins re numbered people to fill holes when the database Compact utility was run. However that was a consequence of the database engine which flagged records for deletion, hiding them from the user as though they no longer existed until Compact was run to actually remove them - the database table automatically re numbered the rows, therefore, revised record numbers. SQLite, the db engine in RM4+, operates differently - records are immediately deleted but the record numbers remain unchanged, I.e., they are fixed, independent of the number of preceding rows. The current Compact operation merely frees up storage space occupied by deleted rows; its actual name in SQLite is Vacuum, for good reason, because it is not the Compact operation of xBase engines.

I, too, would not want my database to be re numbered to fill holes in the RIN sequence and objected to the Compact behaviour of RM3 and earlier. While I do not base my filing system on RIN, I have come to remember record numbers for a few important ancestors and find that handy when using RootsMagic explorer, alt+R is the fastest search path to a person. So I'm content with having a Compact that does not renumber.

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.


#13 D. Spencer Hines

D. Spencer Hines

    Advanced Member

  • Members
  • PipPipPip
  • 38 posts

Posted 20 May 2014 - 09:37 PM

I want a Compact that DOES renumber but I don't want it done in a hidden fashion automatically, as RM3 and Family Origins allegedly did, if you are correct.  I want to control it myself from within the program, with discrete commands.

 

...And that's what Legacy 8.0-Family Tree allows me to do.

 

D. Spencer Hines



#14 Renee Zamora

Renee Zamora

    Advanced Member

  • Admin
  • PipPipPip
  • 8553 posts

Posted 26 May 2014 - 11:39 AM

Confirming enhancement request is in our tracking system. Though I highly doubt we will ever see that happen. I've already mentioned why. Just because Legacy Family Tree does something doesn't mean it's ahead of us in any way, they are actually using old technology behind their software. We decided to stop this practice a long time ago, and use programming tools that are current. TomH gave a good description on what is happening. 


Renee
RootsMagic

#15 SEfromNC

SEfromNC

    New Member

  • Members
  • Pip
  • 2 posts

Posted 27 October 2014 - 12:10 PM

This answered my burning question - what does RM do with the Record Numbers.  I have used TMG for years and was using my TMG numbers for census reports, records of vital records and so on - to refer to the individuals in my database - and make it easier to identify WHICH James Dougherty I was refering to, for example.  I did not want to lose several years' worth of records.  Now I can (not easily but possibly) use my TMG numbers as Reference Numbers.  Any new people will get the RM Record Number as a Reference Number.  I was concerned about the "holes" in the records as I merged people and if they were filled as I compacted  See now I don't need to worry about that.  Thank you for the clarification.  Life is good!