GenoPro Home
GenoPro Home  |  Get Started With My Genealogy Tree  |  Buy  |  Login  |  Privacy  |  Search  |  Site Map

GenoPro Support Forum

Gedcom Import bugs

Click to view RSS...
Author Incorrect source handling and muddled custom tags
Posted Wednesday, March 20, 2013 - Post #31497
Legendary Master

Legendary MasterLegendary MasterLegendary MasterLegendary MasterLegendary MasterLegendary MasterLegendary MasterLegendary MasterLegendary Master

Important Contributors
GenoPro version:

Last Login: 2 days ago @ 8:55 PM
Posts: 3,184, Visits: 23,515
A few Gedcom Import problems.

GenoPro assigns all individual event sources (e.g. BIRTh, EDUCation, OCCUpation, RESIdence) directly to the individual when they should only be assigned to the event itself.  In the example below showing the imported gedcom on the left and resulting XML on the left only Source s1i should be assigned to Individuals's Sources.  

The partial handling of Gedcom tags gives confusing and sometimes incorrect results.  e.g. Only the occupation title is taken from the OCCU tag and the subtags other than SOUR are not processed.  But the title is only taken from the last OCCU tag, any earlier ones are thrown away, other OCCU subtags such as DATE and PLAC are moved to custom tags under a occupation custom tag and SOUR is removed.  Unfortunately subtags from different OCCU tags can get mixed under single occupation custom tag. In the example below the XML tag occupation has DATE from the 1st OCCU and PLAC/place from the 2nd OCCU tag.

I find it strange that the BIRT tag can be processed but not EDUC, OCCU or RESI when the structure is similar with common tags like DATE, SOUR and PLAC.

I suggest that if GEDCOM event tags cannot be processed in their entirety then the event tag and all subtags should be copied to custom tags.  I also cannot see the point of renaming some unprocessed Gedcom tags and leaving others.  e.g. OCCU renamed as occupation, PLAC as Place but EDUC, RESI and DATE are left unchanged.  It would be clearer if the custom tags retained their GEDCOM tag names, unless the subtag was converted to a standard GenoPro tag e.g. SOUR to Source with a reference to the related SourceCitation, DATE to Date and recognised as a GenoDate object, PLAC to Place with a generated reference to a created Place object. 

Also if multiple occurrences of event tags cannot be processed (e.g. OCCU in the example, but also EDUC, RESI etc.) then a warning should be given in the log regarding the lost/omitted data.  But I suggest subsequent tags could simply be given a suffix, e.g. OCCU, OCCU_1, OCCU_2 etc.

The GenoPro XML for a 'half-way house' towards full support for Gedcom import could look like:

<Individual ID="I1">
  <Name>Source Bug
    <Display>Source Bug</Display>
  <Position BoundaryRect="-242,231,-158,155">-200,200</Position>
<Place ID="place00001">
  <Name>1st School</Name>
<Place ID="place00002">
<Place ID="place00003">
  <Name>2nd occupation place</Name>
<SourceCitation ID="s1i">
  <Title>individual source</Title>
<SourceCitation ID="s1b">
  <Title>birth source</Title>
<SourceCitation ID="s1o">
  <Title>1st occupation source</Title>
<SourceCitation ID="s2o">
  <Title>2nd occupation source</Title>
<SourceCitation ID="s1r">
  <Title>residence source</Title>
<SourceCitation ID="s1e">
  <Title>education source</Title>

'lego audio video erro ergo disco' or "I read, I listen, I watch, I make mistakes, therefore I learn"
Posted Wednesday, March 27, 2013 - Post #31538
Grand Master

Grand MasterGrand MasterGrand MasterGrand MasterGrand MasterGrand MasterGrand MasterGrand MasterGrand Master

Important Contributors
GenoPro version:

Last Login: Wednesday, August 3, 2022
Posts: 1,553, Visits: 30,814
I have been using the gedcom import to collate data from census material and exchange with other users. Within GenoPro you can identify changes of occupations and address, identifying them by date and particularly by source. The Report skin will export the data but as mentioned above the import is incomplete.
Having processed many hundreds of files I have found some other problems. Some of these are minor, such as the lack of the file import icon on the menu bar which means two clicks are needed to open the menu instead of one. Also the sub menu of File has several options where a letter is underlined, which conventionally means use that letter with the Ctrl key eg Ctrl+I to open File Import. Only the ones showing the Ctrl+ work.
More important is the action at import. I have not worked out why, having clicked Import, it is necessary to close the menu by clicking the Close button. The information displayed is also in the Message Log. Although the Browse button is active and you can select another file, this can not be imported until the previous menu is closed. So can this step be removed? It is not a problem for occasional import but after a few hundred is tiresome.
When the import has completed the new data is often on top of existing records, even when one is selected. This is not a particular problem and deciding where a suitable empty space exists is not a trivial task and would probably still not be where the user wants the data to go. I find it best to centre the display where I want the new data.
Even this is not without problems. As more data is imported GenoPro often decides to reduce the zoom level and can place the new data off screen. Again experience suggests press the Home key to find and centre the new data, which may need moving away from on top of existing records.
Having imported data there are occasions where it appears to disappear completely. I think this has been reported previously, possibly in another context. I had an example today which I will describe.
I have imported 125 families which were moved to GenoMap1. Move to GenoMap2 for new import (to avoid problem of zoom change). Import a family to the centre of the display and put the cursor over the horizontal slider to move it to the left, and the record disappeared. Zooming out did not find it so I used the feature which has worked in the past, to Display Page Layout. In this case the layout was empty - see zoomed out image. An alternative way to find such data is the Home key but if the display has been touched the selection is cancelled.
I have saved the data at this stage but the saving moved page layout on to the data.
Posted Monday, September 2, 2013 - Post #32360
Grand Master

Grand MasterGrand MasterGrand MasterGrand MasterGrand MasterGrand MasterGrand MasterGrand MasterGrand Master

Important Contributors
GenoPro version:

Last Login: Wednesday, August 3, 2022
Posts: 1,553, Visits: 30,814
Update on disappearing screen display.

I have now got a (large) saved file where I can reproduce a screen anomaly.
To enter gedcom data I am using a blank GenoMap to import 10- 15 families which are then moved to the place where they are needed. A bookmark back to the data entry map and repeat.
This works 2-3 times and then when the first new set is imported the display zooms out and the new data are not visible, until the Home key is pressed. Bit more data on this.
The initial entry GenoMap has co-ordinates (Top left: bottom right)
76184,829; 78055,-98
After ‘zoom out’ the co-ordinates are
20330, 9690; 57700,-8850
Home produces
58000,9694; 95800,-8850.

I have taken this file and tested in on a laptop and get the same effect. (Both XP). In some cases it seems that saving the file after moving from the data input area can stop this behaviour. However this does not always cure the problem
Posted Sunday, September 8, 2013 - Post #32397
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

GenoPro version:

Last Login: Tuesday, March 11, 2014
Posts: 4, Visits: 16
I became a member on 8 March 1953. I can't seem to access my file, and keep getting this message, followed by a long strand of data that, as a layman, don't understand. How can I access my family tree?
[SqlException (0x80131904): Incorrect syntax near 'by'.]
Thank you for your help.


Similar Topics

Click to view RSS...
Expand / Collapse

Reading This Topic

Expand / Collapse