Family Historian User Group

Apologies if I’m stating the obvious, but until you are sure the modified script is doing what you expected, it is always prudent to work with a copy of your database, not the original.

I found it convenient to create a C:\Python\Data folder and copy my GEDCOM file there. Send output to the same folder. To run, open a command window, navigate to that folder, and run the script just by entering py yourscript.py. Minimises typing, and once working as planned, update with your actual input and output files and modify the batch file.

Hi, I have download the original file again and edited using notepad:

The output from running my batch file is:
the two changed lines (using Notepad) are:

input_file = 'C:\Users\David\Documents\Family Historian Projects\David\David.fh_data\David - Copy.ged'
output_file = 'C:\Users\David\Documents\Family Historian Projects\David\David.fh_data\David Ancestry Update.ged'

and the first few lines of my FH Gedcom copy (opened in notepad)

0 HEAD
1 SOUR FAMILY_HISTORIAN
2 VERS 6.2.7
2 NAME Family Historian
2 CORP Calico Pie Limited
1 FILE C:\Users\David\Documents\Family Historian Projects\David\David.fh_data\David.ged
1 GEDC
2 VERS 5.5
2 FORM LINEAGE-LINKED
2 _VAR VUL
1 CHAR UNICODE
1 DEST FTM
1 SUBM @U1@

Does this help in anyway?

Regards
David

PS I'm a bit puzzled by the line 1 DEST FTM

Thanks for that. I have a hypothesis that I would like to test, please.

Attached is a modified script file, plus a copy of the Family Historian Sample Project.ged data file. Could you please save both of these directly to a C:\Python\Data folder, and run directly from the command line (without any modification) by entering py FH2Ancestry101.py. My output from this is shown below:
If this works correctly, please edit the script file to use your own data file and repeat. If that run ok, everything is fine. If you still get errors, rename the sample project file to something else, and modify the script to refer to this new file name. If the errors persist, the problem must be something in the script file formatting rather than the data file, as the data file is known to work correctly.

Will give that a go. Thanks.

Hi Mark,
The screenshot shows the results of my trials: The first run is is using your test files as instructed. All well
The second run is amended the script to run with my files in their original location. Fail
For the third run I copied my files to C:\Python\data folder, script adjusted accordingly. A successful run

It seems the problem lies with the file path.

Regards David

try using \\ rather than \ in the path.

You need to escape the backslashes, alternately forward slashes will probably work.

Jane, that should not be necessary in Python scripts, and is not the case in Mark's scripts.

Fine, when I googled Python and backslash it suggested the escaping was required.

Will test that out and report back, probably tomorrow now, as at work

I think we are sorted now, thanks to all for testing and inputs. Trial and error experimenting and a bit of internet research gave me the following:

The key difference between what worked and what didn't was the Windows path and filename. Back-slashes do not routinely need escaping in Python, but do when the combination with the following character is interpreted as a special character or control code.

'C:\Python\Data\David - Copy.ged' is fine, as neither \P nor \D have any special meaning. The "gotcha" for most Windows users is that \U is the prefix for a 32-bit Unicode character, so any absolute path along the lines of 'C:\Users\MyUserName\Documents...' will fail!

I hadn't noticed that before, as my default Documents folder is remapped to OneDrive on a separate drive, so my absolute path of 'D:\OneDrive\Documents\Family Historian Projects\Draper\Draper.fh_data\Draper.ged' is ok as none of \O, \F or \D have any special meaning so do not need escaping.

The fix is either to double back-slash throughout (so 'C:\\Users\\MyUsersName\\Documents...') as superfluous double back-slashes do not do any harm, or prefix the pathname with a lower case r, as in

input_file = r'C:\Users\MyUserName...'

This causes Python to regard what follows as a "raw string", i.e. a string literal, so all characters are interpreted as written, with no special meanings. The alternative work-around of using a forward slash, as in most other operating systems, is fine for standard Python, but does not work with the codecs library that is required to handle the UTF-16 GEDCOM file that is the FH default.

If we get positive reports from (ideally several) users that this works ok, I can upload a new master copy of the script. It is worth keeping the modification introduced in version 1.01, as this has Windows style CR/LF line endings that work in any text editor. The original version was written on a Linux machine, so while the Unix-style single byte endings don't cause any problems for any half-decent modern text editor, Windows Notepad doesn't tick either of those boxes, so can't display the file properly.

Wonderful, so now the error message makes sense. Bit of a Gordian knot methinks. Thank you Mark.

The Export Gedcom Plugin - Resizing media (16281) posting has an updated Plugin V3.6.3 prototype that fixes the problem of Roots Magic not supporting blank Individual names.

Just an update, have run the script successfully. Loaded into Roots Magic and looks good. Been too busy this week to progress further. Many thanks, think this will prove to be very useful.