4 Replies Latest reply on Feb 6, 2017 3:34 AM by wimdecorte

    Import Best Practice



      What is the best practice over import.

      I recently ran into a stupid problems after an import on a (silent) open file

      (it's for updating, migration)


      The solution was close with a found set in a table - did knew FM was preserving states, but it makes sense.


      But it is not quit explain in the import script steps that it only import found sets...

      In the FM help Doc, it is said that "close" files gets full import, but not open ones...


      Anyway, what is the best way to update a solution with a clone.

           • openning the bkp, performing find all and sorting on all table

           • closing or how do I switch solution - they have the same names !!

           • going back in my clone, activating table/model

                • doing that import

                • openning (silent) the bkp file for serial upadating


      Do I miss something here

      What is your patern on that, tx

      Have a greet Super Ball !!!

        • 1. Re: Import Best Practice

          The files do not have to have the same names.


          I would open and do a show all on every table of the source file. I would prefer to import from a closed file to avoid the need to prep found sets in the source file, but when importing multiple tables, you have to enter credentials with each import.


          Note that you can set up a container field and a script such that an open file dialog opens that the user uses to select the source file from which the script then imports the data.

          • 2. Re: Import Best Practice

            Hi! Phil


            The way I did set things and what I want to do is : to control the BKP file of my solution from the newelly created solution - the update.

            And it seems to not work at all : I think we can't open and control another file, its tables / models, and call on it the show all script step, etc.


            I tryed without result.


            Even renaming it's window name, I couldn't call the activate script step to make it show a particular table.

            Remember my scripts runs on my newelly updated solution and I'm trying to work (close or open) on a BKP of that (BKP.fmpur) solution.


            When I migrate I simply do a bkp of the folder containing the runtime solution and put aside my new one.

            Starts my update and call my Import script. I would have prefered to not open the BKP file but for updating the next serial value you don't have choice.


            But the main problem that I have - now - is that I didn't install a mecanism that would assure me that the BKP file

            when close, closes with or opens with all table too show all records and be sorted.


            My new version will have that on closing and opening as my client don't care about the solution States.

            I read somewhere that if the file is closed it will automatically show all rec - you tell me that I would have to get my credential on ever loop... - but I have to open it after for the next serial value.


            I tought that by openning the BKP file (and not setting is hiden visibility) that I could control it and ask for all tables to show up, call show all rec and sort them, and then going back to my main (the call update that runs the script) file a continue with the next serial value, etc, etc.


            So I will open my bkp prior for that time and show all rec and sort the beast !!

            then close it.


            I don't know if we can actually call another table via the activate script step and sets the table/model from calculated value and do it by a formula that would resolve to Base name (my BKP), then table name (my BKP file::table name) ?


            Have any clue on that !


            tx a lot Phil

            • 3. Re: Import Best Practice

              "Call another table" does not make sense.


              You can use perform script to perform a script in another file. Originally, you asked for a standard or "best approach" and my answer was to that question.


              Now we have the question of how to handle a specific situation and that will require a different answer. You either add the needed show all script to the original file or you make sure that the file is closed each time import records is used to import data from the original file. The fact that both files have the same name should not be a problem. The file reference used to import data is actually a file path this combines the files name and it's location.


              However, to avoid possible confusion, the files need not have the same name. Note that I have not recommended renaming any window but rather the file.

              • 4. Re: Import Best Practice



                But it is not quit explain in the import script steps that it only import found sets...

                In the FM help Doc, it is said that "close" files gets full import, but not open ones...



                I don't think there is a real best practice; it really comes down to what your intended result is.  If you want all records then write your code to do so.


                I tend to never rely on these implicit behaviors like you quote from the help because:

                - now you have to control whether the file is not accidentally open

                - you have to remember the default implicit behavior; I were to debug your script and you left no comment or reference to the help then I would not be able to explicitly read what your intentions are.


                So whenever you want to import records: open the source file and prep the found set