Jump to content
Sign in to follow this  
Cortical

Clone changes import script mapping

Recommended Posts

FM9Av3 MacOSx.5.3

have an import script configured:

Specify data source: using relative path

Specify Import Order:

select arrange By: matching names

select Import Action: update matching records, add remaining

set a match field pair, changes Arrange By to Last Order

click OK, check autoenter, click import to close

open to check and the setup has changed; Arrange By is now Custom Order

Save as a clone, and the import script step has now changed to

Import Action: Add New records.

Quite different to the update matching, add new

Saving the original as a copy, produces the same import settings as the original.

Is this mutation in configuration when cloning a known issue?

If a clone is not actually a clone, then this is of some concern.

Is there a workaround other than save a copy and delete all records all tables, and reset serials etc. ?

Share this post


Link to post
Share on other sites

Is the problem that the file is a clone, or that the tables are empty? Get a copy of the file, delete all records, and then check whether the problem still exists.

Share this post


Link to post
Share on other sites

The problem is that the import configuration defined in the original file, mutates when that file is cloned. So the cloned file has a different script configuration from the original. It should be exactly the same.

The problem only occurs in a clone, a copy and delete all records/all tables has the exact same import script definition as defined in the original.

Edited by Guest

Share this post


Link to post
Share on other sites

I have also built a simple test file to test this. The result is the same, define a update matching import, is mutated in a clone to import new, as per the below:

Original:

import

Go to Layout [ “TblA” ]

Import Records [ Source: “file:export/TblA”; Target: “TblA”; Method: Update matching; Add remaining; Character Set: “Mac

Roman”; Field Mapping: Source field 1 match with TblA::AID

Source field 2 import to TblA::txt

Source field 3 import to TblA::txt2 ][ No dialog ]

COPY:

import

Go to Layout [ “TblA” ]

Import Records [ Source: “file:export/TblA”; Target: “TblA”; Method: Update matching; Add remaining; Character Set: “Mac

Roman”; Field Mapping: Source field 1 match with TblA::AID

Source field 2 import to TblA::txt

Source field 3 import to TblA::txt2 ]

[ No dialog ]

CLONE:

import

Go to Layout [ “TblA” ]

Import Records [ Source: “file:export/TblA”; Target: “TblA”; Method: Add; Character Set: “Mac Roman”; Field Mapping: Source

field 1 import to TblA::AID

Source field 2 import to TblA::txt

Source field 3 import to TblA::txt2 ]

[ No dialog ]

If a clone is not in fact a clone, i.e. an IDENTICAL copy sans data, then this has serious implications.

Share this post


Link to post
Share on other sites

"matching import, is mutated in a clone to import new"

There are no existing records in the table to match the imported data against. So they'll all be new records.

I don't think this is a problem with the cloning process, I think it's caused by the empty table. Did you do the test I suggested earlier?

Share this post


Link to post
Share on other sites

I think you nailed it, Vaughan ... one would think the import would hold but an import with "Update and Add to" cannot be defined within a script if there isn't at least one record. FM simply won't allow it. And I would bet that breaks an empty clone. Should it allow mapping if there are no records? IMO, yes but that is not standard behavior.

Every time I discuss import/export process in FM, I feel my fire rise. Here FM is touting how great it is at handling external data but the import process was designed by a 5-year-old and it hasn't been improved upon in YEARS.

LaRetta

Share this post


Link to post
Share on other sites

"And I would bet that breaks an empty clone."

I don't think it's the cloning that's the problem, it's the empty table. In fact I've done a test and proved that it's not, and the clone isn't "broken" either.

Get the "broken" clone and create *one* record in the table, then check the script again. The import mapping offers the "update" option and it's selected.

The FMI software engineers have done *exactly* the right thing: disabled an option when it's inappropriate, offered the only available option, but remembered the original setting for Ron*.

*Who's Ron? Later on. (It's an Aussie joke).

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.