I've been doing a lot of reading on how to create an import script for updates I send to my clients, merging different copies of the same database, etc... It imports from one copy of the database to another. The records are different, but everything else is the same.
However there are several points I'm having a hard time finding info on. I am using the import records script step. As recommended on several forums, I'm using the insert file script step to invoke a file browser. The user chooses the target file, which is inserted as a reference into a container. Fron there I grab the file name in a variable and move on to the import script steps- one for each table. My issues:
- I can specify the target table, but not the source table when using a variable file path. I found this solution from Soliant Consulting: http://www.soliantconsulting.com/blog/2014/01/mapping-scripted-imports-variable-paths. Basically I add a second path to the specify data source window. This is a full path and thus enables the 'source' table selector. This full path is then broken when I delete/move the file (as, of course, it won't exist on a client's machine). However, it still points the import script to the correct source table in the target file. This method is working for me, but I wanted to ask the community if there were alterante, "supported" ways of making the target table import from it's corresponding source table. in a closed file. My initial hope was that it might import from the correct table since they had the same name, but this doesn't seem to be the case.
- I am not opening the target file and thus do not need to be worried about found sets. However, I've read several posts where developers were having issues with credentials. For each import script, they would be asked for a name and password. I am not having this problem (all auto login options are off in the target and source files). My concern is that I'm missing somethng and will run into this scenario under different circumstances once my solution is deployed. Does this problem only pertain to certain scenarios? Or perhaps the issue was resolved in FMP13?