Importing GEDCOM Fails

I've seen this, as well. You'll find that the more records you have, it will process some, but usually leave the last INDI (and FAM, I think) blank for some reason.

I'm working on a fix for this, and early results are promising.

Same problem, also records that do import are confused.
http://test.vfwpost3894.org/family

Found a few logic errors in the import code so I'll be working on it. Basically reads the next record before saving the current one. Anyone else looking at this?

This patch has been superseded. See comment #8
This is a fairly large change to the import.inc file but it works better for me than the older version. It is still under development and does not read all the available tags in the GEDCOM 5.5 Standard. The working concept is to associate a particular GEDCOM primitive function with each tag within an array, then to navigate the array using the GEDCOM input file with a recursive function that drills down (up?) to each GEDCOM level. Please don't consider using this patch for a production site unless you are willing to accept the shortcomings. Also note that YOUR ENTIRE FAMILY TREE WILL BE DELETED if you check the "Replace existing GED data" checkbox. (Default)

Here is a more complete patch for importing GEDCOM file data. Not all the standard tags are imported but mostly it is because the family tree nodes have no specific properties to store them in. I've done a sort of hack on the header tag, for example, storing an unprocessed list of information from the header into the family node's revision log property. It is not very elegant but it gives those nodes that are imported some kind of history that they came from a gedcom file. The cross references are read into a temporary array, rather than a database table, so that you may no longer split up the gedcom file into smaller chunks. I had a little trouble importing a file containing over 1500 records, but no problem at all at 500 records. Notes at the individual level are properly imported to the node body along with one or two more tags like burial place. I decided that this practice would make the data more difficult to export later so there are only a couple. Also gedcom repositories are placed into location nodes.

Thanks for the patch, it really solves many issues I had with importing GEDCOM data.

However, there is a problem with family_NAME_PERSONAL function.
This is the format in my GEDCOM data.
1 NAME FIRST MID/LAST/

This is the result in the db after import.
title_format = MID/LAST, FIRST - YEAR
firstname = FIRST
middlename = (empty)
lastname = MID/LAST

Also, divorce data is not imported. Looks like adding the following item in family_define_ged_structures() should do it ?
'DIV' => array('primitive' => array('family_event_prefix', 'DIVprefix'),
'substruct' => 'FAMILY_EVENT_STRUCTURE'),

Thanks again.

Your fix for the divorce data looks like it should work fine. Sorry for the oversight. If you've been perusing the import code you'll see the comment I left in the personal name function. I worked out a fix for you, but it might be quicker to simply edit your gedcom file and insert a space just before the first slash to separate the surname from the middle name.