Filemaker's response regarding import bug

[Sxeptomaniac]

I posted a while back regarding an import issue with FM 7v3. When attempting to split repeating data into separate records as part of an import, non-repeating data is not populated like it should be. Here's Filemaker's response regarding the bug:

In regard to having trouble with the option to split repeating data in

separate records when importing into a FileMaker Pro 7 file, the version

2 update to FileMaker Pro 7 should alleviate this issue. If you do not

have a FileMaker Pro 7v2 cd, and you have a personalized license key you

should be able to download the v2 trial to downgrade your copy of

FileMaker Pro 7. The FileMaker Pro 7v2 trial download link is listed below:

http://fmdl.filemaker.com/TBUB/fm/7/Win/fmp_7v2_trial_win.zip

...

Is it just me, or does anyone else find downgrading to fix a bug ridiculous? At this point, I think I'd prefer to script workarounds to this issue.

[dkemme]

I think they are wrong, I had the same problem in v2 and wrote a script workaround. Never tried in v3 though.

[JamesL]

It is a ridiculous solution indeed, and worse, it's even not true what they say, it's a shame that until this moment no fix for this serious problem has been offered by Filemaker.

By the way, I think it's quite strange that a scripted solution that includes splitting repeating data into seperate records, a solution I made in FP 5.5 and converted to FP7 v3, works perfectly in FP7 v3.

My solution appears not to be affected at all by the bug of "non-repeating data not being populated like it should be", but the bug is turning up every time when doing the import seperately.

Who else has found out about this, and how could it be explained ?

[Sxeptomaniac]

I ultimately decided on using workarounds rather than going back to 7v2.

I ended up either using a looped script to go through all the fields and fill in blank data using the Insert from Last Visited script step, or changing the repeating field to a related record displayed in a portal and using two import steps, the second one matching imported data using the key field.

[JamesL]

Sxeptomaniac, I just found out that we were working out the best solution at about the same time but in different continents.

I started out on the way of least resistance: in the source file using the non-repeating field I defined an "extend" repeating field.

Not being pleased with such a cheap solution I abandoned it and, like you, I ended up using a looped script to go through all the fields and fill in blank data using the Insert from Last Visited script step.

I admire your alternative portal solution, and I keep on looking forward to Filemaker's fix.

[JamesL]

Sxeptomaniac pointed out 2 different workarounds for the "split records" import bug

the looped script workaround upon import is clear to me,

but I am curious to know how to proceed with the second solution he mentioned briefly:

- changing the repeating field to a related record displayed in a portal and using two import steps, the second one matching imported data using the key field.

I hope somebody can tell me how to do this.

[Sxeptomaniac]

Here's the related record workaround for this. I'm going to assume you know how to create a related table and portal. Just set them up with the same fields as you would have with the repeating field, using a key from the parent table. If you previously had data in the repeating fields, you will need to import the data using the first workaround mentioned

You do your first import with the sub-table, which was formerly your repeating field. You want to make sure that once you're done importing, your found set in the table imported to is only the data you've just imported, though. If you have other records in found set, this next import may overwrite data. I often start by doing a find all records step, then show omitted only, before the first import, but this doesn't always work correctly for some reason (another bug?). As a result, I often do a find after the first import based on a field I will know to be only empty in records which have just been imported.

You then import from the parent table, but to the bottom left of the import dialogue you can choose the option to "Update matching records in the existing set." You can then choose one or more fields to define the match, by clicking on the arrow for importing until you see an "=". Only records where the data in these fields matches will be imported.

That's all. I know it may be a little confusing at first, so you may want to experiment with this process.

[JamesL]

Sorry, but I still don't see how to get this portal solution working.

Since my repeating field file always contains previously entered data,

the first workaround (just a simple looping script that can be easily

adapted to other files) has to be used beforehand anyway.

The portal workaround seems to require rather much (extra) work, but I'm

interested in understanding it's logic.

I would very much appreciate if you could illustrate your explanation

using the simple file I set up (certainly incorrect and incomplete), and

attach here. It has the 2 tables: the repeating field table and the portal

table. (My problem starts with: the key from the parent table).

It's the "Catalogue number" I want to see in each split record, together with one of the repeating field values of "AuthorName".

repeatingsplitimportportaltest.zip

[comment]

Your file seems cross-wired in terms of tables and their relationships.

In any case, I believe there is a simpler way to work around the bug - see attached.

splitRepeating.fp7.zip