Given that it's been working perfectly for such a long time, the following seems unlikely but perhaps it's worth checking anyway? For the '0' records table/ layout, that the layout/ table occurrence is still precisely as it should be? If this is so, then if there's a duplicate layout? (even less likely!)
Good luck with it,
Thank you for your time and suggestion. It really has never worked well. I always have to verify that all the data matches and frequently the script needs to run a couple times or more before it does. The issue tends to be that a table still doesn’t show all, even though a script ran that should have performed that.
I have also discovered that somehow the script step for import on that table was somehow corrupted. When I deleted it and rewrote it, it then worked.
It would be nice to use the intended behavior of importing all (without opening the file) without having to put your identical credentials in 25 times, that makes no sense to me.
Yes, we do this maneuver so often, it should be a built in function
if it's only one table, it might have scrambled record id's. Try importing into a clone of the SOURCE database, to clean it up
to avoid the password problem, try running the process from a third temporary file, with matching passwords
>The script then goes to each of the layouts that have the records of the 25 tables and imports the records. Now I am consistently getting zero records from one table, when I go to that layout it appears to show all records.
The best approach is not to open the database, and then I am assured of all records. However if I don’t open the database I am asked 25 times for the password (both files have the same credentials). Very frustrating! There has to be a better native to Filemaker way.
Have you considered adding the second database to the front-end as an external data source, then creating layouts or relationships (if necessary) to import your data acurately on a regular basis?
Of course, I would recommend creating a new script and script steps (as context-free as possible, using script parameters!) by following your documented logic — or, the previous script upon which it is based.
Is there anything you've done to mark records that could not be imported due to record-locking on the records they are attempting to update, and are you even trapping for that?
I'd also be curious to know more details about the import configuration script(s), but the root cause has not yet been determined without a more granular analysis of the factors involved, which may include the schema, calcs, field types, scripts, and layout info.
Please be sure and give us an update or reach out for more assistance.
- - Scott
Thanks GD, it was a currupted script step!
The empty database is how I update my solution. I use a customers existing database and data, then import in to the updated/revised solution.
I know there is a 3rd party solution out there, but this process works well as I also check and compare the records/tables after the import.
What does not work consistently is the need to have all records show. Filemaker has a built in solution for this, simply do not open the database.
Unfortunately what seems to me is a flaw, is the need to sign-in each time. As both databases have the same creditials no sign-in should be required (IMHO).
Scott's is agood suggestion.
You only need 1 TO for each table in the "from file" . (Not sure you even need a layout) So the foundcount for the source table should never be an issue.
Please look for information on how to deal with corruption. Someday you will be glad you did because if the file is corrupted then it will rear it's ugly head again. If Murphys law is a constant then it will happen at the worst possible time