7 Replies Latest reply on Feb 3, 2015 2:57 PM by philmodjunk

    FM 13 Adv 05 --- New version requires import from different table

    synergy46

      Title

      FM 13 Adv 05 --- New version requires import from different table

      Post

      I have developed membership v 2.40.  It has a new table called 'Military Awards'.  Prior versions do not have this table.  Military Awards is the source for a List Popup.

      I have crafted an import script that imports from the Source table into the Target table then looks at the Target table.  If it finds Target::TotalRecords=0 then it imports from another  Target::'Import Table'  which holds the default Target table values.

       

       

      The problem:  When I run this script, it keeps trying to use a Source table with the same name as the Target table.  Is there a way to specify the Source table (which is just a different table in the Target)?  (Yes, I have manually specified the Source table but it keeps reverting)

      Thanks

      Ron
       

      militarypopupimport.png

        • 1. Re: FM 13 Adv 05 --- New version requires import from different table
          philmodjunk

          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:

          $ThisFileName
          file:FileNameOfFIleThatexistsatTimeScriptStepIsCreatedHere

          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.

          • 2. Re: FM 13 Adv 05 --- New version requires import from different table
            synergy46

            Hi Phil,

            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.

             

             

            • 3. Re: FM 13 Adv 05 --- New version requires import from different table
              philmodjunk

              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.

              • 4. Re: FM 13 Adv 05 --- New version requires import from different table
                synergy46

                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-)

                • 5. Re: FM 13 Adv 05 --- New version requires import from different table
                  philmodjunk

                  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

                  • 6. Re: FM 13 Adv 05 --- New version requires import from different table
                    synergy46

                    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 ?

                     

                    Ron

                    • 7. Re: FM 13 Adv 05 --- New version requires import from different table
                      philmodjunk

                      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.