Jump to content


Photo

Compare files doesn't work

compare comparison

  • Please log in to reply
15 replies to this topic

#1 ljwolfe

ljwolfe

    New Member

  • Members
  • Pip
  • 4 posts

Posted 26 August 2018 - 03:49 PM

I've seen other people discuss similar problems, but don't want to hijack someone else's topic.

 

As a test, I made a copy of my file. As in, using File Explorer, I copied and pasted so there were two identical files. I ran it through another program to confirm that the two files were bit-for-bit identical.

 

Then I opened one in RootsMagic, selected compare files, didn't change anything, selected the identical file, and RM found hundreds of people who it thinks are 96-99% matches. Skimming the many individuals, one problem is it will see relatives (spouses, children) in a different order and flag that. But I didn't change any settings between opening the first file and comparing it to the second.

 

How can I trust comparisons for purposes of merging, or for looking for changes between two versions of a file (yesterday's vs today's, for example), when I know the program finds differences between identical files? Is this even on RootMagic's radar as a bug, or is it something we just have to live with? Or is there a trick to making it work (as in, not find differences where there aren't any) that I'm not aware of?

 

Thanks.



#2 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6130 posts

Posted 26 August 2018 - 08:10 PM

You do have some that score 100%, don't you?

 

How I imagine it works is quite different from doing a byte by byte comparison. It is going to test a number of fact types, e.g., Birth, Death plus Name and possibly the parents and spouses of a given person for a match. Let's say there are 5 such fact types and each is weighted the same. If the person has 4 of those 5 fact types and they obviously match on the comparison database, then the score would be 80%. For events that have both Date and Place, if both match (empty fields cannot match), then 20% would be allotted; if only the Date matched and the Place was empty, then 10% would be allotted for that event.

 

That doesn't take into consideration whether the sources factor into the comparison - I don't know. But the main point is that, while the OS file compare reports that the files are identical, a perfect match, and therefore the records for a person in that file are perfectly matched, what the RM File Compare is doing between files is similar to what it does within a database in Duplicate Search. The latter gives you control over what criteria are used to score the comparison; the former does not.

 

An interesting exercise for you to do is to copy a tree twice from one database into a new one without merging and see what Duplicate Search reports with the default settings and how it compares with what you got from File Compare. 


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.


#3 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3366 posts

Posted 26 August 2018 - 10:31 PM

When the Compare Files feature was first introduced into RM, I did the same test of comparing two absolutely identical RM databases with the same bewildering results as reported by ljwolfe. In my case, RM's Compare Files found thousands of mismatches. My conclusion was that RM wasn't really doing a compare in the sense I think of when various utility programs similar to the UNIX diff command are used to compare two sequential files. Rather, it feels like the Compare Files feature is using logic similar to the logic used by Duplicate Search Merge, except that it is extending the Duplicate Search Merge logic across two files.

 

I can see both good and bad aspects to the way RM's compare files seems to work. For comparing an RM database to itself, I think RM's Compare Files is useless. For comparing my RM database of today to my RM database as it was two days ago or two weeks ago, I think RM's Compare Files is useless. But suppose a fellow researcher sends me an FTM GEDCOM of all the descendants of John Doe. I could import that GEDCOM into a new RM database A and do a drag and drop from my production RM database into a new RM database B, selecting only the descendants of John Doe from my database. Having set up RM database A and RM database B in this fashion, I think RM's Compare Files feature could be somewhat useful. 

 

But I think the greater need and one that is not being met is the UNIX diff command type of comparison between two RM databases. Such a comparison would be most useful if there could be a perfect or near perfect matching between individuals in the two RM databases. And if the two RM databases have somehow or other been produced from the same original RM database, then RM's UID field (Unique ID field) would be the perfect way to do the matching.

 

Because RM's Compare Files does not provide the UNIX diff command type of functionality, I have never actually had a situation where it was of any value to my personal research. I'm really surprised when other users occasionally do report success in using Compare Files. They must be doing something right that I'm doing wrong.

 

Jerry

 



#4 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8287 posts

Posted 27 August 2018 - 01:09 PM

When a person has multiple facts of the same type they are compared against each other. This will cause the match score to lower.


Renee
RootsMagic

#5 ljwolfe

ljwolfe

    New Member

  • Members
  • Pip
  • 4 posts

Posted 27 August 2018 - 04:37 PM

"You do have some that score 100%, don't you?"

Yes, that's why I said 100s instead of 1000s.

 

"It is going to test a number of fact types, e.g., Birth, Death plus Name and possibly the parents and spouses of a given person for a match. Let's say there are 5 such fact types and each is weighted the same. If the person has 4 of those 5 fact types and they obviously match on the comparison database, then the score would be 80%."

And when both people have 5 of 5 facts with the same info - same dates, locations, notes, and sources -- then shouldn't it be 100%? But it isn't on far too many people.

 

"When a person has multiple facts of the same type they are compared against each other. This will cause the match score to lower."

Which, again, makes the file comparison virtually useless. Say two people both have five census facts -- 1900, 1910, 1920, 1930, 1940 -- with identical info for each relevant year. If RM can't tell that those people are identical, then I have to manually check each person, and then what's the point of having a comparison? Same with children. Two people have exactly the same kids, in the same order, but the comparison swaps the order of children on one set (or both, but differently) and then flags the parent as different. :-(

 

I'm with Jerry -- as it stands, for most reasons a person might want to compare files, the built-in comparison is useless. If something happens and I want to compare my current file to one from a little while ago, or if someone sends me a file with mostly the same family and I just want to see who's actually different (as opposed to having to slog through 100s of people who RM says are different even though they aren't), I might as well just create reports and then go through them by hand.

IMO, they need to either make it work, or take it out.

And by the way, if the files are identical, then that means that every single person in the file is identical -- same facts, same family, same sources, same color code, same groups, identical. I'm not sure how people could think identical files could have people who are different between the two files.



#6 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3348 posts

Posted 27 August 2018 - 05:45 PM

How can I trust comparisons for purposes of merging, or for looking for changes between two versions of a file (yesterday's vs today's, for example), when I know the program finds differences between identical files? Is this even on RootMagic's radar as a bug, or is it something we just have to live with? Or is there a trick to making it work (as in, not find differences where there aren't any) that I'm not aware of?
 

 

The Rootsmagician did say Compare Files is a Work in Progress here

 

I'm with Jerry -- as it stands, for most reasons a person might want to compare files, the built-in comparison is useless.

 

Many of the duplicate identification routines mainly Duplicate Search Merge yearn for improvement imo and Compare Files is not one I have yet found useful but a good start.

 

I'm not sure of your motives but I do have great confidence in the robustness of Automatic Merges. Since you are in a test phase, screen shot the Properties of your file, drag the second copy into your file and screen shot the Properties again, they should have mostly doubled. Now run the Automatic Merges and wait, then check and screen shot the Properties again, they should mostly return to original.

 

Try the same experiment again but add one additional event to any person, the end file after Automatic Merges should be +1 Event.

 

I'm a sceptic at heart but I do have confidence in Automatic Merge but be aware if you have made a change to an event in one file you will end up with a duplicate of that event in the merged file and Date Last Update does not always captute those differences.


“Your most unhappy customers are your greatest source of learning.” -Bill Gates

 

 

User of Family Historian 6.2.7, Rootsmagic 7.5.9, Family Tree Maker 2014 & Legacy 7.5 (in order of preference)

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#7 kbens0n

kbens0n

    Advanced Member

  • Members
  • PipPipPip
  • 3437 posts

Posted 28 August 2018 - 12:39 AM

The title of this post is subjectively misleading. Of course it works !
What about the express purpose of the menu item... to compare NON-EXACT copies of database files? The OP is off in the weeds about the 96-99% matches of an exact copy of the database.
It is unfortunate that the side effect of using the Duplicate Search/Merge is that parent, sibling, spouse and children comparison obviate the need to compare all those variations of Record #'s against each other ...versus a linear scan of already-ordered field differences... but it is a necessary evil for the purpose it was added (non-exact copies of databases). Try using a binary or textual diff tool on even a moderately different set of files and then try to make heads or tails of the great disparity in presentation ;-)

I just explored this feature for the first-time and even those 96-99% matches (of an exact copy) brought to light a number of glaring problems I have in my own database.
I've only spent 15 minutes (up at this late hour) in examining from 96% to 97% and I'm discovering data entry/import errors such as:
-Duplicated <Blank> Unknown Spouses that I thought Database Tools Phantom Records would have removed
-Duplicate spouses with close spelling variants that pointed to the need to merge them
-Multiple sets of Parents linked, that possibly should not be
-Duplicate exact facts
-Duplicate inexact facts, where one might have a Place,Date and/or Source that the other(s) did not
-Duplicate Marriage facts
-Spouses that should have had an associated Marriage facts but did not (ie. 5 Spouses but only two Marriage facts)
-My 15 minutes was up, I had written down the Record #'s for "return to fix" and I still had "100s" to weed through

---
--- "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


#8 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3348 posts

Posted 28 August 2018 - 05:15 AM

I just explored this feature for the first-time and even those 96-99% matches (of an exact copy) brought to light a number of glaring problems I have in my own database.

 

I was excited this morning and thought kbenson may have hit on a hidden use for this feature but I have not found such things worth highlighting in my own database on a very quick look at only 99% matches, I will drill further when I have more time.

 

However I do see some yellows which when comparing the person in each copy which should not be highlighted, I need to scrutinize this further and it would hopefully be worthwhile for any of us who have the time to formalize this for the benefit of Rootsmagic development. I don't have time at present but will certainly be loking at this again when I do as any flagging of data anomalies is worthwhile

 

Two things I do notice very quickly is the sorting of children causes false differences as ljwolfe stated and there is something weird going on regarding Alternate Names.


“Your most unhappy customers are your greatest source of learning.” -Bill Gates

 

 

User of Family Historian 6.2.7, Rootsmagic 7.5.9, Family Tree Maker 2014 & Legacy 7.5 (in order of preference)

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#9 ljwolfe

ljwolfe

    New Member

  • Members
  • Pip
  • 4 posts

Posted 28 August 2018 - 02:42 PM

The title of this post is subjectively misleading. Of course it works !
What about the express purpose of the menu item... to compare NON-EXACT copies of database files? The OP is off in the weeds about the 96-99% matches of an exact copy of the database.

Thanks for the insult </sarcasm> And I did get those results. I could post a series of screen shots (way too many to get in one screen) if you don't believe me.

My point was to give an example of the far-too-numerous false negatives that come up in file compares. If I compare two files that are similar, but NOT exact, to see what the differences are (which is the "express" purpose of the function), it would take hours to weed through all of the people who are identical but the compare flags as different, in order to find the people who actually are different and need to be addressed. As I said earlier, in this case (comparing "NON-EXACT copies of database files") the feature is broken. It's almost faster to print out a report and compare everyone visually.

Looking for duplicates in a single file (Duplicate Search Merge) is a different use, and one that is marginally useful, but I wasn't posting about that function. RM is OK at finding people who are mostly the same for that use. But it's terrible at just finding people who are different.

But, for the pedants, I'll see if I can change the subject line.



#10 ljwolfe

ljwolfe

    New Member

  • Members
  • Pip
  • 4 posts

Posted 28 August 2018 - 02:43 PM

OK, I can't seem to change the subject. Unsurprising, really, and understandable. So consider it to read "...doesn't work properly." Because it doesn't, as others besides myself have noted.



#11 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6130 posts

Posted 28 August 2018 - 09:48 PM

Whether Duplicate Search or File Compare, the score must be regarded as a crude estimate of the probability that two people could be the same person, based on their respective facts. Say you have a John Smith in your database with no other facts. Now you File Compare your database with its copy. So FC pairs up the John Smith in each db; what probability can it surmise that they are the same person from the only matching fact, the name. It can't be 100%; logically, the probability has to be low: 10%, 1%, 0.1% are all the same to me. Add another John Smith to the test db with no other facts. Same low probability. Now add identical vital events to one pair of John Smiths. The probability should go up for that pair but not for the other pair; despite the added events to one John Smith, there is no further match than the name with the other John Smith so no higher probability. Based on the individuals' facts, I'm not sure what set need to match for File Compare to declare 100%.

For a person in a duplicate database or one who has migrated from a reference database to a test database via one or more drag'n'drop or GEDCOM transfers via intermediary databases, File Compare was enhanced at my request to compare the hidden UID that RM assigns to a newly created person and preserves through transfers. There is an infinitesimally low probability that any RM database will generate an UID that is identical to another. File Compare flags that a pair has matching UIDs.

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 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3348 posts

Posted 29 August 2018 - 08:35 AM

OK, I can't seem to change the subject. Unsurprising, really, and understandable. So consider it to read "...doesn't work properly." Because it doesn't, as others besides myself have noted.

 

I agree that it doesn't work properly even with EXACT file copies of a file, maybe it should be called Crude File Compare  <_< 

 

Whether Duplicate Search or File Compare, the score must be regarded as a crude estimate of the probability that two people could be the same person, based on their respective facts. Say you have a John Smith in your database with no other facts. Now you File Compare your database with its copy. So FC pairs up the John Smith in each db; what probability can it surmise that they are the same person from the only matching fact, the name. It can't be 100%; logically, the probability has to be low: 10%, 1%, 0.1% are all the same to me. Add another John Smith to the test db with no other facts. Same low probability. Now add identical vital events to one pair of John Smiths. The probability should go up for that pair but not for the other pair; despite the added events to one John Smith, there is no further match than the name with the other John Smith so no higher probability. Based on the individuals' facts, I'm not sure what set need to match for File Compare to declare 100%.

For a person in a duplicate database or one who has migrated from a reference database to a test database via one or more drag'n'drop or GEDCOM transfers via intermediary databases, File Compare was enhanced at my request to compare the hidden UID that RM assigns to a newly created person and preserves through transfers. There is an infinitesimally low probability that any RM database will generate an UID that is identical to another. File Compare flags that a pair has matching UIDs.

 

I can't agree, Duplicate Search Merge and File Compare are both different utilities with different goals, File Compare should only display differences of less that 100% and where there is a distinct difference. Identifying distint differences is the job of the coding and logic applied behind the scenes and there are currently deficiciencies in that logic.

 

So FC pairs up the John Smith in each db; what probability can it surmise that they are the same person from the only matching fact, the name. It can't be 100%; logically, the probability has to be low: 10%, 1%, 0.1% are all the same to me.

 

Where the Name, Record Number and UID are the same then it is the same record, one could even use Last edited date for extra sanity checking

 

For a person in a duplicate database or one who has migrated from a reference database to a test database via one or more drag'n'drop or GEDCOM transfers via intermediary databases, File Compare was enhanced at my request to compare the hidden UID that RM assigns to a newly created person and preserves through transfers. There is an infinitesimally low probability that any RM database will generate an UID that is identical to another. File Compare flags that a pair has matching UIDs.

 

Your suggestion for UID comparison was strikingly obviously and a good one, my brief observations are not via drag'n'drop or Gedcom transfers were file differences will obviously creep in. I am seeing very obvious false negatives regarding child sorting as stated by the OP and something weird regarding Alternate Names where no differences exist. As I said before I do not currently have the time to study this further on behalf of Rootsmagic but like NameClean and PlaceClean the logic behind File Compare needs to be strengthened without simply moving on to another new feature and ignoring these deficiencies.

 

 

A quick test on which I welcome opinions;

 

1. Make a copy of your database in Windows Explorer.

2. Use File Compare to compare both copies of the file.

3. Examine and try to understand those individuals where the %Match scored less than 100%

4. Screen shot the properties of your copy database.

5. Drag one copy of the file into the file used for step 4 selecting 'Everyone in the database'

6. Go to Tools>Merge>Automatic Merges and Begin merge with all options checked.

7. Once completed open File Properties and examine against your screen shot from step 4.

 

 

Question, Did Rootsmagic Automatic Merges perform a merge on some individuals where it did not have 100% confidence level in those individuals being identical? I suppose this boils down to which routine has the less robust logic and personally I have build up a high confidence level in Automatic Merges over the years through extensive testing.

 

 

FC-test-results.png

FC-test-compare.png


“Your most unhappy customers are your greatest source of learning.” -Bill Gates

 

 

User of Family Historian 6.2.7, Rootsmagic 7.5.9, Family Tree Maker 2014 & Legacy 7.5 (in order of preference)

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#13 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3366 posts

Posted 29 August 2018 - 08:52 AM

This has been a very useful and thought provoking thread. I have especially appreciated the messages that I didn't totally agree with because they really made me think!  :)   In that spirit, let me offer a couple of additional and possibly contrarian thoughts.

  • I don't think that events and dates and places are the most important genealogical data. I think the most important genealogical data is simply names and relationships (parents, children, and spouses). So what if you don't have the place or date where William Doe was born. What matters much more is that William was the father of John Doe and that you have evidence for such fatherhood. I'll sometimes discuss family history face to face with a relative. And in so doing, I'll sometimes give my paternal line all the way back to the Bryan who was my immigrant ancestor from Ireland (early 1700's). In so doing, I will only give names and not dates and places. The names and who was the parent of whom is really what's most important. But search criteria and matching criteria seem to focus on events and dates and places and to ignore relationships.
  • I think that typical searching and matching criteria are additive and that they should be subtractive instead. For example, suppose you have two individuals in your database named John Doe and you have no other data for either one of them. And for the moment, let's assume that that you have no relationship data for either one of them (see the first bullet point). Then in my view, these two John Does are 100% match because there is nothing that doesn't match. Now add birth information for both and one of them was born in 1750 and the other was born in 1890. Now we can subtract off the date mismatch and they are a 0% match. But if one of them was born about 1796 and the other was born about 1798, I wouldn't subtract off very much. Maybe they are a 98% match. If one of them was born in Kentucky and one of them was born in Tennessee then there is a reasonable chance they were really the same person who was really born in the same place, so you wouldn't subtract off much more. But if one of them was born in Kentucky and one of them was born in New York, then you would subtract off much more and maybe they are only a 20% match. The details of the subtraction algorithm would require a lot of work and a lot of tweaking to be effective, but if done well I think a subtractive algorithm ought to be much more effective than an additive algorithm. And most matching and searching algorithms seem to be additive algorithms where the more pieces of data that match the higher the score. 

 

The matching algorithms used by RM's Duplicate Search Merge and Compare files remind me a great deal of the search algorithm used by the ancestry.com search engine. Well, most genealogical search engines do it in a fashion similar to ancestry.com, but let's focus on ancestry.com. The algorithm used by ancestry.com presents its result in a star system instead of a percent system but it's the same concept. 5 star matches are like 100% matches, 4 star matches are like 80% matches, etc. and half stars are supported so 4 1/2 stars are like a 90% match. I find ancestry.com's searches that are ranked by stars to be almost completely worthless. A typical search will yield millions of matches and the matches that the search puts at the top of the list are almost never valid. So instead I use ancestry.com's exact search tools, and I use them for all of my searches. These tools do include wild cards in names, date ranges for dates, and adjacency searching for places (e.g., Jefferson County, Tennessee and all adjacent counties). Using ancestry.com's exact searching tools in this manner very seldom gives me false positives and I very seldom fail to find what I'm looking for if indeed it's there. But one key is that I try to limit the amount of data in my search. Putting a birth date into the search automatically eliminates records such as city directory data that don't have birth dates. Putting a marriage date into the search automatically eliminates records that don't have marriage dates. Etc.

 

I think that RM's DSM and Compare Files could be much more effective if they would (perhaps optionally) adopt some of these ideas - calculate a percentage match subtractively and ignore data that's not there, take a more exact match approach (with data ranges and place adjacency and name similarity taken into account), and especially take relationships into account.

 

Jerry



#14 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3348 posts

Posted 29 August 2018 - 09:47 AM

This has been a very useful and thought provoking thread. I have especially appreciated the messages that I didn't totally agree with because they really made me think!  :)   In that spirit, let me offer a couple of additional and possibly contrarian thoughts.

  • I don't think that events and dates and places are the most important genealogical data. I think the most important genealogical data is simply names and relationships (parents, children, and spouses). So what if you don't have the place or date where William Doe was born. What matters much more is that William was the father of John Doe and that you have evidence for such fatherhood. I'll sometimes discuss family history face to face with a relative. And in so doing, I'll sometimes give my paternal line all the way back to the Bryan who was my immigrant ancestor from Ireland (early 1700's). In so doing, I will only give names and not dates and places. The names and who was the parent of whom is really what's most important. But search criteria and matching criteria seem to focus on events and dates and places and to ignore relationships.

 

Jerry, you frequently challenge my communication skills and often logic and thats very welcome and a good thing, think we were typing at the same time just there.

 

I suppose what I should have said was 'in the absence of anything else, Names, Dates and Places are vital clues' , a bit like Names, Dates and Places being the bricks and the family links being the cement which prove and hold them together. When we do a jig-saw puzzle we do a preliminary sort of edges, corners, bits of sky, machinery, fields etc. that's who I often how I try to describe things geographically and often disprove suggested family links.

 

I read your post with great interest and very though provoking as usual, I just hope Bruce is listening and cares enough to give your points consideration.

 

BTW, your early 1700's ancestor came from a Townland in Ireland and that Townland is still here and very likely the boundatries are unchanged ;) if you find another individual of the same family Name in the same Townland in the same timeframe, well ???

 

Jackson


“Your most unhappy customers are your greatest source of learning.” -Bill Gates

 

 

User of Family Historian 6.2.7, Rootsmagic 7.5.9, Family Tree Maker 2014 & Legacy 7.5 (in order of preference)

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#15 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3366 posts

Posted 25 September 2018 - 07:25 AM

In response to this thread, I have played around a little bit (a very little bit) with some SQLite queries that might be the beginnings of a binary difference kind of compare between two RM files where the files are expected to be largely the same. For example, you might be comparing your RM file of today with your RM file of yesterday or last week or last month. What I'm talking about wouldn't work if you were comparing your production RM file to a new RM file created by importing a GEDCOM from a competing genealogy program.

 

In my initial playing around, all I did was to run what SQL calls a JOIN operation between the PersonTable in two different RM databases. In my case, my two databases were my RM database from today and my RM database from a week ago. A JOIN operation is essentially a matching operation. For example, suppose you have two lists of numbers list_1 = 7, 14, 19, 22 and list_2 = 7, 14, 22 and if you match up the two lists, it's immediately obvious that the two lists are nearly the same. You could create list_1 from list_2 by adding 19 to the list and you could create list_2 from list_1 by deleting 19 from the list.

 

RM's PersonTable doesn't contain quite as much data as you might expect because names are stored in a different table called the NameTable. The reason for storing names in a separate table is that each individual can have more than one name by using RM's Alternate Name facility. So matching up my PersonTable from today with my PersonTable from a week ago didn't tell me very much because I only matched on the UniqueID field. Every person in your RM database has a UniqueID that is not very visible from the RM user interface but the UniqueID is preserved across a GEDCOM export/import cycle. The UniqueID was introduced into RM when the ShareMerge feature was introduced into RM, and as far as I know ShareMerge is the only thing that the UniqueID is used for. In any case, it served my purposes very well of matching two different copies of my PersonTable with each other. Basically what I was able to do with this very simple query was to identify anybody whom I had added or deleted from my database within the last week.

 

In a way, identifying additions and deletions is not very much, but in a way it's a lot. But as much as anything, it exemplifies the sorts of things you can find out with a simple minded matching process. For example, if in addition to matching on UniqueID I had also matched on the Color field, I could have identified all the people in the database for whom I had changed the color coding in the last week. Or if in addition to matching on UniqueID I had also matched on the EditDate field, I could have identified all the people in the database for whom the Last Edited date had changed in the last week. So I think this approach has great promise. I do think it would be a great deal of work to bring this type of compare to fruition. In particular, you would need to include many additional RM tables into such a matching process.  And in any case it would also require a second copy of my database with which to compare my current database. But I think it's something to think about.

 

Jerry



#16 kbens0n

kbens0n

    Advanced Member

  • Members
  • PipPipPip
  • 3437 posts

Posted 25 September 2018 - 09:23 PM

You might want to experiment with sqldiff.exe https://www.sqlite.org/sqldiff.html

---
--- "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






Also tagged with one or more of these keywords: compare, comparison