FileMaker Error 729
Errors occurred during import; records could not be imported
Comments
Hubert Oct 5, 2017 |
||
I can report another strange one with the import script step throwing error 729. - The first import script step imports only one record from an xml source into a table to verify the xml source file. - If the check succeeds and after a user confirmation a second import script step imports the data from the same xml source (options: updating matching records, adding remaining records). - This throws error 729 on the second import; however, only on some windows machines, never on Mac's - the first strange behaviour. - One user of an affected Win machine then waited about 15min(!) before confirming the import - it then worked. How strange is that? I can only assume the script cannot access the file and therefore fails. Hubert There is some good news: This issue goes away with FM16... |
||
DigitEL Sep 13, 2017 |
||
Appears the following... If importing with 'Perform Auto Enter options...' selected, check Field Definitions... - No 'Always' Validation use 'Only During Data Entry', definitely causes props - Consider disabling all Validations as possible - Consider disabling all auto-enter calculations as possible - Avoid LookUps in destination file if no relationships exist from destination file to where source file obtained lookup data - Consider converting calculation fields to text/number/date data fields especially if destination file is for data storage - In Import Field Mapping disable import from any fields that are not necessary to destination file purpose - Summary fields seem ok if reference only internal data fields and can be useful... Import of even 1 record may not work if any of above is in play... I suspect if even one validation, lookup, calc, or relationship errors then import stops... HTH EL |
||
Alex S Apr 22, 2016 |
||
Alex SL I don't know how you figured this out but I also just got this error. It totally prevented me from importing by hand instead of script. Thanks for taking he time to post here guys! | ||
Alex SL Dec 21, 2015 |
||
On my FileMaker database, I had a field with required not empty value. Since the import had empty values for this field, I got that 729 error. | ||
Chiyoko Yoshida, chiyoFM, LLC Nov 29, 2015 |
||
I just encountered this error with FileMaker 14. A scripted import brought in the data but I got this error. Turns out it was due to externally stored containers. My import script step need the option to "Preserve external container storage" checked in my case. This got rid of the error in my case. Hope it helps someone in the future. | ||
Mike Beargie, Anvil Dataworks Aug 22, 2014 |
||
We encountered this issue again on an import records script step. An ODBC / ESS table was the destination for the import, but the ODBC user had read-only access to the destination table. | ||
Mike Beargie, Anvil Dataworks May 12, 2014 |
||
We had a client experience this error in their file. It was due to the import destination having a field that requires a unique value. There were duplicate "names" in the source data for import, and we could prove that the record with the later creation would not be imported because the name was not unique. Solved by removing the unique requirement temporarily and showing the client how to search for dupes. |
||
Peter Roots Dec 11, 2013 |
||
Suddenly had this vague error on a scripted import, and a manual import would not work. When I tried to create a new record manually I then got the message that another user had Manage Database open; after they'd got out all was fine again. | ||
anonymous Feb 11, 2013 |
||
This error can also occur if an attempt is made to edit a database while someone is editing a record. Even if the "Waiting to Commit Changes" pop-up is canceled, this error can still occur as long as the database management window is open. Tested in FileMaker Pro Advanced 12.0v3 connected to FileMaker Server 12.0v3. | ||
Gull-Britt Nylund, Norsult Nov 6, 2012 |
||
Hi, I got this error 729 by a customer as (wrongly) a field was imported into a field defined as having unique value. It worked for years correctly, and then suddenly the field to import contained a value already existing in the table. |
||
Atalanta Feb 26, 2012 |
||
I was banging my head about this lovely code. I tried not importing the fields that were validated and still got the error. Since I had a shared field (I'm importing to modify a found set) on the layout I tried to enter data into the field and got a much more useful error - Record is in use and unable to be modified. Ah HA! Once I exited the record (in the file that was to receive the imported data), it worked! | ||
Wendy Oct 31, 2011 |
||
I got error 729 when attempting to import into a locked record. Was expecting 301, but I suppose 729 makes sense. | ||
Kelly, n/a Mar 4, 2011 |
||
I have this issue even when not using a script and importing a sample CSV file. It will import 3 of 10 records. A new database with the same file works so it must be somewhere in this file. (not the data/format) |
||
E.J. Sexton, TourTech Systems, Inc. Apr 13, 2010 |
||
I ran into this problem when I was duplicating scripts and then modifying the "Import Records" script step for different tables. For some reason, the script step was not working for duplicated scripts. When I deleted the "Import Records" script step and recreated it, the problem seemed to go away. |
||
Ross Mackintosh, DataMate Solutions, LLC Apr 6, 2007 |
||
I have been getting this error alot on a current solution. When I imported ALL fields I got no error. When I selected only desired fields, I got 729... Even weirder I tried process of elimination. First imported all fields no problem, took fields out of the import step a few at a time and it worked still. So I guess we have learned nothing :) | ||
Matt Sawyer Sep 18, 2006 |
||
One of the most useless error codes ever devised. We know theres an error, a hint would be good | ||