When using a variable to specify the file, you also need to do a bit of a trick or none of the field mapping is retained in the script step.
Set up your file reference like this:
That second reference has to be a valid reference to a file, but only at the time you set up this script step. Then you can specify the source table, target table and field mapping and all of this info--generated from the reference to the actual file, will be retained in the script step.
I got it to work. This is what I did:
I created a new .fmp12 file called Import.fmp12. It has one layout and one table; Imports. In that table are the 86 default records. In my script, I hard code Import.fmp12 as import file. When the import step is run, it automatically shows the single table in import.fmp12 and maps accordingly..... Seems to work.
yep but using a variable can be set up to work as well. It just depends on whether that is needed or not.
I sometimes set up an "update" import by setting up a layout with a global container field and a script that does an Insert File Script to insert a reference to a file into the container field.
The user runs the script, insert file presents them with a dialog for finding and selecting the file and then, with the reference inserted into the container field, a set variable step sets a $Path variable to a file path extracted from the container field for use with the Import Records Script step.
In my situation, I have already collected the import file name and path into $$Path and $$FileName.
My main application is called Membership.fmp12
What I needed was to import data stored in a different table in Membership.fmp12 Without the inclusion of Imports.fmp12 in the runtime, FM keeps telling me that I can't import a table into itself and does NOT allow me to 'automatically' (via script) select the table. (I suspect this is where your variables come in)
But, including Imports.fmp12 in the build seems to be the simplest, least convoluted way to get the desired outcome. I don't have to ask the user where the table is located and they don't have to browse to it. The table is in Imports.fmp12 and the resulting Imports.fmpur file is included in the application in the same directory as Membership.fmp12. I am lazy so I usually go for the simplest solution. 8-)
What I have recommended from the beginning is that your Import records step include a file reference with BOTH the $Path variable and the hard coded reference to a file. You use the hard coded reference to set up and keep the table and field mapping specified, but when the script runs, it refers to the file specified in the $path variable. From what I see in your script, it looks like your script ignores the variables and just uses the hard coded reference to the file.
More on this and other uses of a $Path variable can be found here:Exploring the use of a $Path Variable in Scripts
You said: it looks like your script ignores the variables and just uses the hard coded reference to the file.
Right. Since the imports.fmpur file is in the same directory as the application I don't seem to need the path. It seems to be working. Am I wrong ?
No, just pointing out that you aren't actually using the variables. If the file to be imported is a file whose name and location is always the same, you don't need a variable.