Thank you for your post.
I am unable to replicate the issue using your files with FileMaker Pro 14.0.6 and FileMaker Pro 15.0.2. I never receive the <Field Missing> option in the Import Dialog.
In the second file, the order is incorrect. I added back the Num field, set the Import order, ran the script to make sure it worked, and then deleted the source Num field again. Running the script again matches the Txt and Date fields appropriately.
Creating a new file in FileMaker Pro 14.0.6 and FileMaker Pro 15.0.2 worked similarly.
Let me know if you have better steps to execute so I can replicate the issue.
1. Create file 'Test'
2. Create table ’S’
3. Create fields a,b and c
4. Create table ‘D’ with fields d, e and f
5. Create script ‘imp'
6. Create step Import Records
7. Set file path to file:Test
8. Set source table to TO ’S’
9. Set target table to TO ‘D’
10. Set import order a->d, b->e and c->e
11. OK and Save script
12. Delete field b
13. Check the import mapping again.
14. You should see where field b used to be.
Thank you for the sample file.
I now see the issue. Like you, once I save the custom order and get the import error warning, the correct fields are still mapped.
I have sent your test file to our Development and Testing departments for review. When I receive any feedback, I will let you know.
Testing has confirmed the issue. All information has been sent to Development for further review.
I would like to bump this issue and underline the importance of this 'lost' feature.
1. Rock solid data quality
Import Records is used substantially within our solution (and other solutions) to move data around in the database. It is used all over the place to duplicate and convert documents and line items: from products to product-variations to quotes to offers to delivery notes to invoices to payment reminders to accounting to payment to statistics, etc., etc.
Such core business data may typically pass though around 10-15 import processes in its lifecycle, as it passes through the various tables of the database.
These import processes need to be rock solid!…
…even in an environment where data requirements are constantly in development, meeting the needs of a changing society and growing customer needs. Fields come and go - they come not infrequently and occasionally also need to go!
The import processes need to be able to withstand the tide of change!
Rock solid data quality can only be guaranteed, when the Import Records script step maintains a list of the SOURCE field ids. This protects the import process from nasty side-effects when creating and deleting fields.
WITHOUT the vital information about the source fields, import processes are very susceptible to even the tiniest changes in the database design (e.g. adding a field).
Should a developer create or edit an Import Script step using FM 15 it BREAKS the step, losing the vital source field references, leaving the import process open to the woes of change.
This makes db-maintenance very labour intensive, requiring us to check import processes after every created field.
3. Support for fileMaker 14
Until this bug is fixed we are forced to use FileMaker 14 to fix and edit our import processes.
It is also the case, that we shall need to install FileMaker 14 on customer servers to fix & maintain the import processes there - a very irritating requirement.
Similarly, until this bug is fixed FMI will need to maintain support for FileMaker 14!
I understand from the FM Roadmap that the Import process is due to be revamped in "FM Beyond", maybe FM17, ... but I would beg you to consider fixing the problem in an fm15 rev, and for sure in fm16 … because waiting till fm17 is far too long to have fm14 in active use.
FBA Platinum Partner
Günther Business Solutions GmbH
I have attached your entire post to the original report.
I had similar issues with 2 customers. I was about to build a example file to send to you but then wasn't able to replicate the issue again.
What I do:
I've duplicated the data-file USRD.BZZ and named it USRD2.BZZ, then started a script to import all records from USRD2.BZZ into USRD.BZZ.
After import-script completed, two Relationship arguments altered:
EAN_Nr = f_EAN
AND discipline = Discipline
Print_Kto_Nr = f_EAN
AND ?? = Discipline
as a consequence, a script with 'set Fields' function broke.
I had to install a FMPro Demoversion to fix those customers Runtime.