Thanks again!

I'll leave myself at a stand-still, then. I was thinking of cleaning up
the file via merges of identical copies, but not if there's the
slightest chance of corrupting things further. I'll leave this one for
the experts :)

  Ed

On Sun, 2005-09-11 at 19:04, Wm Voss wrote:
> This appears to be the case. I have done some tests with the sample 
> file, straight export and import, that has produced some very odd -- and 
> corrupting -- results.
> 
> Wm Voss
> 
> Ed Barnard wrote:
> 
> >Jeremy,
> >
> >The main point might be getting missed here.
> >
> >1. There was no export. Ever. Only import and intellishare/intellipass
> >merge.
> >
> >2. The same database did NOT trigger the spurious-differences problem
> >before converting to the new format.
> >
> >My procedure since March has been to close my legacy file, upload a copy
> >to our server via ftp, then continue on working with my legacy file.
> >Meanwhile, my partner (also with deluxe, always same build date, we stay
> >in sync) downloads that server copy via ftp, does editing, and puts her
> >copy back up. I then download that copy via ftp, and with my legacy file
> >open, do file->import->legacy file... checking the boxes to import
> >everything, no autosource assigned.
> >
> >This procedure has worked fine (subject to other limitations of
> >intellishare merging) until upgrading to the new database format. We now
> >have the spurious-matches problem in latest V5 build, and V6.
> >
> >The current theory is that Legacy is altering the text as it is
> >imported.
> >
> >Thanks to everyone for the help!
> >
> >  Ed
> >
> >On Sun, 2005-09-11 at 18:42, Jeremy Main wrote:
> >  
> >
> >>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
> >>    
> >>
> >
> >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