What might be a temprary alternative to Behold - Categorized in: General Discussion

Given that Behold won't write a (corrected) GEDCOM file for some time, what might be the best alternative to use in the meantime to avoid having to go over the issues which will arise as more data is entered.

IOW, which application available now will cause the fewest headache if and when I switch to Behold
so I can carry on with editing and adding to my data til Behold is ready? ;-)

Or are they all more or less equally problematic?

What you propose is a very thorough research project of comparing the major apps in this respect.
The time and expertise needed for this I suspect is well above my level of experience and background.
Even if only done with my current app, it will only get me so far because I suspect I would not necessarily detect output which ends up in the wrong place or may have been missed - due to the sheer volume.
<rant> :-)
Export is only one part of this problem.

Surely a developer would only add input fields to his program if he had a way or the intention of outputing the data - even if only for on-going use in the logic; excepting of course data which is output only if certain options are set - and then one needs a global way to override the exception, as you pointed out in your stack-exchange comment.

Inputting the data in a way that encourages quoting and recording sources and makes it as easy and intuitive as possible is the other part and a very important part of this process is making it easy for the user to validate his data as part of the input process.
The same goes for almost any other data.
I find it incredible that some apps do not verify things as simple as date conformity with the standard they claim to adhere to, let alone other inconsistencies. Mind you, I have really worked with very few apps, so I may have a biased and mal-formed impression.
Though, if an app accepts user input, rather than just gedcom, then, IMO, it is incumbent on the app to make reasonably sure the input is 'reasonable' and if at all possible, it should verify as much as possible at the very time of input.

It is nice to have a separate, one time validation option/phase, but it would save a lot of time and frustration (especially for newbs) if the app complained if someone's third grandfather supposedly died at the age of 345 years, because somebody entered a bad date along the way :-)

The sooner, the better and also because so many validation logs end up too long and not specific enough a week or even years after the data causing the problem have been entered (wrongly)
</rant>

Hi Louis and Arnold

I've been using Family Historian heavily (pending Behold!) and with one small caveat* it's gedcoms are accepted by Behold without any errors or cautions. FH uses Gedcom as its file system so there is no conversion to think of.

Cheers, Colin

* FH allows you to create custom events and attributes. So if you create one called Regiment it writes a tag called 'REGI' which Behold reads but warns about. I've been search/replacing all REGI tags to _REGI tags (in Notepad or similar) that FH seems to back accept no problem. So far! But it is a small task to do so for a Behold ready gedcom anyway.

Hi Louis

Yep, Behold will do it right. I was more concerned with having a 'correct' gedcom now, and adding the underscore myself was a simple step to 'regularise' it. If it created problems in FH then I wouldn't bother.

Will Behold will offer the choice of gedcom 5.5 or 5.5.1? I don't know if FH will accept 5.5.1 gedcoms and I would like to be able to port back to FH for the charts etc after doing some edits.

Colin

I'll test - would be good to know. Do you have a test 5.5.1 file to hand? The two that come with Behold are olde stylee and customised for PAF and Legacy.

Louis/Colin,

Was reading through the message threads and came across the mention of Family Historian, my main Family History 'database' program since 2003. As you are aware, Family Historian saves its data to a GEDCOM file rather than a true database (As does GEDitCOM on Mac OS X). However, the 'dialect' of Gedcom does vary according to which version of Family Historian is in use, i.e. the most recent release, Version 6, introduced various new innovations which have increased the complexity of moving Gedcom Files to other programs. Changes in the Gedcom structure used by FH have arisen from a move to the use of Unicode internally (UTF-16), which means that it can store any character from any language and any accent; new support for Witness Citations, and greater support for Places and Mapping all of which get in the way of simply using a native FH Gedcom file for transferring data to other software (See http://www.family-historian.co.uk/features/whats-new-in-version-6 for more detail). To improve data transfer the program does provide a Gedcom Export function which can be tailored in numerous ways to produce a Gedcom file that is 'more acceptable' for importing to other programs/utilities or to earlier versions of Family Historian. The downside of this is that, having exported a Gedcom structure that is suitable for transfer to another program/utility there is obviously a loss of direct compatibility with the internal file structure, so making a 'return journey' of the data to Family Historian is not a straightforward process.

It's also worth mentioning that for Version 5 or 6 of Family Historian, there is a user developed "Export Gedcom File" plugin available which has the capability of creating a wide range of Gedcom dialects tailored to other programs/online services see - http://www.family-historian.co.uk/pluginstore/plugin-entry?id=522 for more information.

So, the point I would really want to put across is that there is really no such thing as a 'standard' Gedcom output file from Family Historian because of the wide variety of options possible, unless the intention is to be able to work with the internal gedcom file structure, which will still vary dependent on how the relatively new Witness and Places functionality have been used; what use is made of Unicode accented characters in individual names, place names etc, etc..

Mervyn

Hi Louis,

Sorry for the delay - this was one of those threads that disappeared and I couldn't get back for few weeks.

So I've just downloaded the three files and tested them on FH5.0.9. Ascii and UTF-8 loaded fine (with a slew of 5.5.1 derived exceptions). The unicode file wouldn't load at all, but FH6 is now UTF-16 natively so obviously will handle this format OK as well.

Anyway I'll email you the roundtrip gedcoms together with hopefully identical backups and screenshots to show how FH displays the 'unrecognised' tags in the program.

Cheers, Colin