Well..... Here's my recommendation:

On import, do not change any tabs to spaces or anything else.
On export, do not change any tabs to spaces or multiple spaces to tabs.
On display/edit of any note field, do not make any data changes (specifically 
do not
convert spaces to tabs or vice versa).

This is based on the theory that the user "did it their way" for what ever 
reason or
display situation they have and Legacy should not make any changes.

When merging it might be possible to clean any note field up a little bit 
before comparison.
However, one must ask if such a programming effort would be worth it (and easily
understandable for the user).  One could consider rules such as the following:
-- compare any note field on a line by line basis.
-- any line made up entirely of spaces and/or tabs would be reduced to zero 
spaces.
   (that is, an empty line made up of just a new line character and no data)
-- all trailing spaces after the last printable character would be removed
-- all leading blank lines (ie: empty lines) would be removed
-- all trailing blank lines (ie: empty lines) would be removed
-- multiple internal adjacent blank lines would be reduced to one (optional?)
   (This one depends on whether one author intended to specifically set off the 
data
    by more than one leading blank line.  These could be (optionally) removed 
for
    comparison purposes.)
-- multiple adjacent blanks within a line could also be reduced to a single one.
   (taking into account tabs as if they were spaces)
   (This last two are based on the assumtion that differences in line spacing 
and
    in column/word spacing are NOT significant for merging considerations.  If 
this
    assumption is not valid for a particular merge situation, then they could 
otionally
    be turned off.)  
-- Then, after the above was done, compare on a line by line basis.

    When difference were found, we could now highlight the differing lines, say
with a background color, pink?  (At least the first one.)  So a visual scan 
would
know where to look for a difference.

     Any difference found would be with visible character data (and not the
invisible data of blanks, tabs, line feeds, and new line characters.)

     This is, of course, a quick summary and does not take into account 
different
GEDCOM character sets or other special issues such as alternate language
character differences.

     Keep in mind that the Legacy Merge operation always puts the lower RIN
number on the left and the higher RIN number on the right and so, by default,
merges higher RIN numbers to lower RIN numbers.  I think it's good practice
to give the import file a very high starting RIN number so that it always 
appears on the right hand side of the merge compare window.  This allows me
to always consider the left hand window the "master" copy of the data into
which I am merging the new data.

     Doing just about any of the above would put some contraints on the current
RTF control that is used to manage note/text fields in Legacy.  But, I think it 
would
be worth it!

Well....that's my two cents worth.
...../Jeremy

---
Glenn Todd wrote:
You may be onto something here.   Computers are notoriously dumb when it
comes to things like this - to them a character is a character is a
character.    Some exception handling code may be necessary either in the
import or comparison code - probably the latter.    Basically it's not a
good idea to use tabs for formatting, since there's no consistency in the
way that they are handled by the display code, but that's no help if a
program "helpfully" converts spaces to tabs to save space in an export.

Glen

-----Original Message-----
From: Jeremy Main <[EMAIL PROTECTED]>
Sent: Sep 11, 2005 6:21 PM
To: [email protected]
Subject: Re: [LegacyUG] Intellishare fails on 6.0 and V5-latest.

More information:

---original----------        ----i imported --------
  1: Notes                  -  1: Notes
  2: "Hexwasxthrownx -  2: "Hexwasxthrownx
  3:                            -  3:
  4: DescendantxRegi  -  4: DescendantxRegi
  5:                            -  5:
  6: 1.tBenjaminxRob  -  6: 1.tBenjaminxRob
  7: xtx                      -  7: xtx
  8: t                          -  8: xxx
  9:                            -  9:
 10: ChildrenxofxBen   - 10: ChildrenxofxBen


Row 8 is an example of the problem.   A singleton tab on row 8 in converted to
three space in the imported copy.  This occurs 12 times in the import.  In all 
cases
the singleton tab was followed by a blank line (a new line character with no 
data), but
I don't know if this is significant.  (Note:  I used "x" to represent spaces 
and "t" to
represent tabs for the comparison.)

To me, this looks like the import is NOT KEEPING the original data (the tabs).  
And
I think this is in error and should be fixed.

I also think this may be closely related to the "spurious" 'abandon changes' 
message
when editing the notes field.   That is, if the process of opening the text 
note for editing
is making this kind of invisible change, then when closing the window, Legacy 
thinks a
change has been made.

.../Jeremy

-----Original Message-----
From: Ed Barnard <[EMAIL PROTECTED]>
Sent: Sep 11, 2005 6:01 PM
To: [email protected]
Cc: [EMAIL PROTECTED]
Subject: Re: [LegacyUG] Intellishare fails on 6.0 and V5-latest.

Jeremy,

That makes all kinds of sense. Thank you!

In theory, then, I should be able to "clean up" my database by
re-importing an identical copy, telling it to preserve the imported
version. Once I get a clean pass, I should be back in business (albeit
tab-free).

  Ed

On Sun, 2005-09-11 at 16:32, Jeremy Main wrote:
> Hi Ed:
>    I believe the problem you are seeing is happening as part of the import 
> and is not an Intellishare/IntelliMerge issue, per se.
> 
>    I've been looking at RIN # 1793 (Benjamin Robertson III) in your original 
> database.  I imported a copy into itself and got the 89 individuals it says 
> it was 'not able to merge'
> 
>    What I've found so far is that the General Notes of both the original and 
> the copy contains 112 lines.  However, the original has 5,321 characters and 
> the copy has 5,345.   So,  there IS a difference after import which 
> IntellPass Merge is detecting.
> 
>    However, the difference is that the original has 132 tabs versus 120 in 
> the copy/import (12 fewer in the copy).  And the original has 847 spaces 
> versus 883 in the copy/import (36 more in the copy).  For a net difference of 
> 24 characters.   (5,345 - 5,321 = 24 ).
> 
>    So.......
> 1)  The import is changing SOME of the Tab characters to spaces,  and
> 2)  IntelliPass Merge is considering these tab/space differences significant.
> 
> I don't think you have a corrupt file.  Only that the import is making some 
> unexpected changes.  I'll look a littler further and tell you exactly which 
> lines are the ones being changed.  Wm's utilitiy, UltraEdit, is probably not 
> considering these differences to be significant.  A visual scan can see no 
> difference.
> 
> .../Jeremy
> 
> -----Original Message-----
> From: Ed Barnard <[EMAIL PROTECTED]>
> Sent: Sep 11, 2005 5:06 PM
> To: [email protected]
> Subject: Re: [LegacyUG] Intellishare fails on 6.0 and V5-latest.
> 
> Ron, Henry, Wm,
> 
> Thanks for the suggestions!
> 
> I've been investigating myself, as well. It now appears to me that I
> have a corrupted database, as someone suggested. The corruption dates
> back to prior to the conversion to the new format, but didn't manifest
> itself until after the conversion.
> 
> Here's what I've tried. (Hopefully Sherry will see this!)
> 
> I went back to a July backup, ~4000 names, same problem. That is, I
> restored from backup, converted to new format, closed, made a copy,
> merged the two copies, got spurious differences in the notes.
> 
> Same with a May backup of ~450 names.
> 
> Early May backup of ~150 names didn't fail; nor did a March backup of
> ~120 names.
> 
> I took the latest master db from my genealogy partner (we always do ftp
> transfers, which should have integrity checking) and followed Ron's
> suggestion:
> 
> I opened the file, did check/repair, did control-b backup, closed,
> restored from that backup, saved, made a copy, imported the copy, got
> spurious differences on the merge - but only about 20 differences this
> time.
> 
> Meanwhile, I have a completely different database (different family)
> which I've not touched since May 9th 2005. I merged two copies, it did
> merge without any differences. So, yes, the problem may well be specific
> to the one database.
> 
> Sherry, when Millenia's able to take a look, please let me know, and
> we'll give you the current database for repair.
> 
> Thanks for the help everyone with the suggestions, and in verifying the
> problem!
> 
> Best Regards,
> 
>  Ed Barnard, maybe a legacy deluxe user again soon
> 
> 
> On Sun, 2005-09-11 at 15:26, Wm Voss wrote:
> > I imported your Original into your Clone and ran IntellShare/Merge and 
> > got 89 records that could not be auto merged, just as you did. I copied 
> > the pairs of notes out of a dozen records and did a file compare in 
> > UltraEdit; none showed any difference at all. I also did compares on the 
> > full family files and on exported gedcoms; no difference found in either.
> > 
> > Beats me what's going on, but I'd sure not trust it until someone 
> > figures out the problem.
> > 
> > Wm Voss
> 
> Legacy User Group Etiquette guidelines can be found at:
> http://www.LegacyFamilyTree.com/Etiquette.asp
> 
> To find past messages, please go to our searchable archives at:
> http://www.mail-archive.com/legacyusergroup%40mail.millenniacorp.com/
> 
> To unsubscribe please visit:
> http://www.legacyfamilytree.com/LegacyLists.asp
> 
> Legacy User Group Etiquette guidelines can be found at:
> http://www.LegacyFamilyTree.com/Etiquette.asp
> 
> To find past messages, please go to our searchable archives at:
> http://www.mail-archive.com/legacyusergroup%40mail.millenniacorp.com/
> 
> To unsubscribe please visit:
> http://www.legacyfamilytree.com/LegacyLists.asp

Legacy User Group Etiquette guidelines can be found at:
http://www.LegacyFamilyTree.com/Etiquette.asp

To find past messages, please go to our searchable archives at:
http://www.mail-archive.com/legacyusergroup%40mail.millenniacorp.com/

To unsubscribe please visit:
http://www.legacyfamilytree.com/LegacyLists.asp

Legacy User Group Etiquette guidelines can be found at:
http://www.LegacyFamilyTree.com/Etiquette.asp

To find past messages, please go to our searchable archives at:
http://www.mail-archive.com/legacyusergroup%40mail.millenniacorp.com/

To unsubscribe please visit:
http://www.legacyfamilytree.com/LegacyLists.asp

Legacy User Group Etiquette guidelines can be found at:
http://www.LegacyFamilyTree.com/Etiquette.asp

To find past messages, please go to our searchable archives at:
http://www.mail-archive.com/legacyusergroup%40mail.millenniacorp.com/

To unsubscribe please visit:
http://www.legacyfamilytree.com/LegacyLists.asp

Reply via email to