1 2 Previous Next 18 Replies Latest reply on Jul 14, 2016 12:15 AM by user19752

    perform script on server: import from self

    William-Porter

      Not sure whether I'm doing something wrong or missing something. Hope somebody can set me straight.

       

      Got a file on server. As a matter of weekly routine, this file needs to duplicate about 1000 records and then make some minor adjustments to them (like adding 7 to a date field, that sort of thing).

       

      I can think of a bunch of ways to skin this cat. Right now, I'm trying to duplicate the 1000 records by doing an import within the file itself. Well, actually, it's two imports. Table can't import into itself. So if the primary data table is called MYDATA, script has to do something like this:

       

      • Find the records in MYDATA
      • Go to layout based on table TEMP and import from MYDATA
      • Go back to MYDATA and import from TEMP

       

      And in fact, it works, great. Unless I try to run that script using Perform Script on Server.  Does an import-into-same-file script step simply not work within a script called by the PSoS step?  If it works, can you tell what I might be missing?

       

      Will Porter

       

      (This is all FileMaker 15 although I doubt that matters.)

        • 1. Re: perform script on server: import from self
          ninja

          I'm looking to do the same thing...but can't.

          Look at thread "Server Scheduled Scripts" from me...

           

          Chocoholic broke the bad news to me:

           

          From the FMI knowledge base article # 7035

          "Import/Export script on FileMaker Server"

          Import/Export script on FileMaker Server | FileMaker

           

          Importing/exporting directly to and from another FileMaker Pro file is not supported via a FileMaker Server scheduled script. The supported import/export formats include:

          <snip>

           

          Let's see if FMP15 answers are different!?!

          1 of 1 people found this helpful
          • 2. Re: perform script on server: import from self
            David Moyer

            Someone please check me on this, but I believe that this can be accomplished on the Server side by first exporting the data to a temporary .TAB or .CSV file (on the server); then importing that file back into your table.

            Yes, field mapping will be a PITA, but I believe that it can be done.  You might also have to deal with potentially incompatible characters:  tab, comma and double-quote.

            Server-side scripts are often required for Go applications.

            (Now, I'm wondering if an export to a .fmp12 file would work, an make it easier to map fields.  Try that first.)

            1 of 1 people found this helpful
            • 3. Re: perform script on server: import from self
              William-Porter

              Eric,

               

              Thanks for reply. I'm familiar with the article that you referenced. But note: It is talking about scheduled scripts. What I'm trying to do is not a scheduled script. The process I'm working on will be kicked off by a user clicking on a button. At that point, the primary script (the one attached to the button) figures out if the file is on server, and if it is, calls the subscript that contains the import-then-reimport steps as 'perform script on server'. If the file is NOT on server, the same script is called but using a simple 'perform script' step.

               

              HERE IS WHAT I SUSPECT. I suspect that using "perform script on server" to import from one table in file X into a different table in file X, simply doesn't make sense. If it's on the server, the import is already being performed there. That is, as far as I can tell, these 1000 records that I'm working with are not downloaded to the local client machine as an invisible cache of data and then uploaded back.

               

              But I can't find any official acknowledgement that PSoS cannot be used to call a subscript that contains a self-import and I'm just hoping somebody here can tell me if what looks to be the case, really is the case, or, if I'm missing something, what am I missing?

               

              Will

              • 4. Re: perform script on server: import from self
                karina

                whats your import path?

                • 5. Re: perform script on server: import from self
                  William-Porter

                  David,

                   

                  Thanks for reply. I'm aware of the possibility of exporting to a temp file (either on server or even on client computer) and I've tested that approach with success. And there are many other ways to skin this cat.

                   

                  If you're simply trying to import from table A into table B of the same file that's hosted on the server, it's easy to do: just include the 'import from file' script step and configure it properly. You can even use a variable for the file name. Works fine and there's no need to download to a file then reimport.

                   

                  So you absolutely can import from a hosted file into itself. What you CANNOT do — as far as I can tell — is put that import script step into a subscript that is called via a PSoS step in a controlling script. It's documented that you can't do this in a scheduled script. And apparently you can't do it even in a non-scheduled script. I'm just trying to confirm.

                   

                  Will

                  1 of 1 people found this helpful
                  • 6. Re: perform script on server: import from self
                    coherentkris

                    perform script on server obeys all of the rules for server scheduled scripts

                    • 7. Re: perform script on server: import from self
                      karina

                      is your import file path something like

                      fmnet:/hostIPaddress/fileName

                      For example:

                      fmnet:/192.168.10.10/database.fmp12

                      • 8. Re: perform script on server: import from self
                        William-Porter

                        coherentkris wrote:

                         

                        perform script on server obeys all of the rules for server scheduled scripts

                         

                        Thanks for weighing in. As I said earlier myself, I strongly suspect that this is the correct and simple answer. (Well I didn't talk about unscheduled PSoS obeying "all" of the rules for scheduled scripts. I only mentioned the issue of importing.)

                         

                        Either way, does FileMaker's documentation so this? Maybe it does and I've missed the official help page that I was looking for. The discussion of scheduled scripts seems to me to imply that there is a difference or distinction between scheduled scripts and, um, those, like my scripts, that are not scheduled.

                         

                        Will

                        • 9. Re: perform script on server: import from self
                          William-Porter

                          Path doesn't matter. As a matter of practical fact, that path used by the Import Records script step is a variable "$filepath". But I've tried every permutation I can think of, and none of them work when the script containing the Import Records step has been called by a Perform Script on Server step. If the same script is called with a "Perform Script" step, then everything works as expected.

                           

                          Will

                          1 of 1 people found this helpful
                          • 10. Re: perform script on server: import from self
                            David Moyer

                            I can't quite nail down what the issue really is (I heard that my answer works and tested, but not a viable solution).  So, just for those following the thread, regarding the export/import path use the Get(TemporaryPath) to create a unique, temporary folder path for each user to write the file to.  This path is different when executed on the Server than on the Client machine (and nothing on a remote Web Direct connection).

                            I'm also concerned that the script, and any subscripts called by that script, are fully "PSoS" compatible, and any subscripts are called via PSoS.

                            Just thoughts, dave

                            • 11. Re: perform script on server: import from self
                              karina

                              We had kind of the same problem. Worked on the clientside not on the serverside.

                              When we used file: and other options.

                               

                              Then we changed the path in:

                              fmnet:/192.168.10.10/database.fmp12

                               

                              And that worked for us.

                              • 12. Re: perform script on server: import from self
                                William-Porter

                                Grateful for interest in this thread, but as the OP, I'm worried about the issue that matters to me is getting confused and that others may also be getting confused. I have the feeling that some of the responses here are responding to a different problem than the one I described.

                                 

                                 

                                So for the sake of clarity, let me answer the question that I did NOT ask. Well, one of the questions I did not ask, but which one or more contributors to this thread seem to have had in their minds.

                                 

                                That question would be: I'm trying to import some records in my hosted database from one table into another table in the same file and I can't get it to work. Is there a special trick to this?

                                 

                                And the answer to that question would be, no, there's no special trick. In fact it's easy. Here's an example in pseudo-script-ese.

                                 

                                set variable [ $filename ; Get ( FileName ) ]

                                 

                                go to layout [ INVOICES ] // for example....

                                 

                                ( find the records that you want to archive )

                                 

                                go to layout [ INVOICE Archives ]

                                 

                                Import Records [ file: $filename ; with appropriate stored options in the "specify import order" or import-field-mapping dialog ]

                                 

                                At which point if I really were invoicing archive records I'd probably go back to the INVOICES table and delete the found records.

                                 

                                Works fine on the server. And that's all there is to it. In fact, it can be even easier than that. If your file's name is never going to change, then you don't need to bother with the $filename variable. In the specify-data-sources dialog associated with the Import Records script step, simply enter the (fixed and unchanging) name of the current file.

                                 

                                Okay, there's a gotcha. Always a gotcha. Even if the file's name may change and you do want to use a variable, you will nevertheless have to enter a literal file name at least once — and perhaps this is where one or two folks are having problems. You can't configure the field-mapping if you've only entered a variable in the specify-data source dialog. So you have to hard code the source file name INITIALLY. When you do that, you'll be able to see the source table on the left of the import-field-mapping dialog. But after you've done the field mapping, you can remove the literal name of the source file from the specify data source dialog and replace it with the variable. The database will remember the mapping even if you can't VIEW it in the script editor.

                                 

                                The other gotcha has to do with the path you store in the variable. If you're doing an import from a file into another table in the same file — which is what this thread was started to discuss — the path is easy. "Get ( FileName )" is all you need, on the server or on a local computer. You could play around with other functions like Get ( FilePath) etc but you don't need 'em.

                                 

                                 

                                How's that different from what I asked? I already had the self-import working perfectly. I simply wanted to know why I couldn't get it to work when I call the import script using a "Perform Script on Server" step. So if the script I described above was named "Archive Invoices", here is what I was looking at. If user clicks a button that triggers the script "Archive Invoices", everything works. But say instead user clicks button that triggers a script named "Archive Invoices \ Branch to server if possible," that looks like this:

                                 

                                     If [ PatternCount ( Get(HostApplicationVersion) ; "server" ) > 0 ]

                                          Perform Script on Server [ Archive Invoices ]

                                     Else

                                          Perform Script [ Archive Invoices ]

                                     End If

                                 

                                That is where my problem arises, not in the script that does the import. And it's pretty clear to me now that this script that branches to server if possible is simply NOT going to work, because (apparently) you cannot use Perform Script on Server to perform a subscript that includes an import.

                                 

                                Will

                                1 of 1 people found this helpful
                                • 13. Re: perform script on server: import from self
                                  William-Porter

                                  karina wrote:

                                   

                                  We had kind of the same problem. Worked on the clientside not on the serverside.

                                  When we used file: and other options.

                                   

                                  Then we changed the path in:

                                  fmnet:/192.168.10.10/database.fmp12

                                   

                                  And that worked for us.

                                   

                                  I'm not going to test this. Let's say it works. But what's the point? Why bother with the network path, when the import records script step works fine when the source file is the current file.

                                   

                                  My script needs to do two things (as I said in my original post):

                                  — duplicate a thousand or so records

                                  — make some changes to the new duplicate record set

                                   

                                  Importing the records already takes place on the server. So it's already happening as fast as it can. What I really want PSoS for here, is for the process of making the post-import changes to those records. So now my scripts look like this.

                                   

                                  First there's what I call the controlling script. I'll pretend that I want to archive a bunch of invoices.

                                   

                                  Archive Invoices: Control

                                   

                                  go to layout [ Invoices ]

                                  ( find some records to archive )

                                   

                                  go to layout [ Invoice Archives ]

                                  import records [ data source: 'Myself' ; etc....]

                                   

                                  if [ PatternCount ( Get(HostApplicationVersion) ; "server" ) > 0 ]

                                       Perform Script on Server [ "Archive Invoices: update archived records" ; with a script parameter]

                                  else

                                       Perform Script on Server [ "Archive Invoices: update archived records" ; with a script parameter]

                                      end if

                                   

                                  And then there's the subscript: Archive Invoices: update archived records:

                                   

                                  set variable [ $scriptparameter ; get ( scriptparameter ) ]

                                  go to layout [ Invoice Archives ]

                                   

                                  ( find the records that were just imported using the info in the script parameter )

                                   

                                  (do some stuff to those records)

                                   

                                  Works beautifully. The only mistake I made initially was that I had put the Import Records step into the subscript. When I tested on my local machine it worked fine, then it broke on the server. Now I know why. Solution: Pull the import out of the subscript — and leave all the other stuff in the subscript so the server can do it super fast.

                                   

                                  Will

                                  1 of 1 people found this helpful
                                  • 14. Re: perform script on server: import from self
                                    David Moyer

                                    okey dokie,

                                     

                                    one more idea:  just brute-force script it.

                                     

                                    - go to the layout

                                    - find the set (unsorted)

                                    - set variables $index (to 1) and $limit (to the found count)

                                    - loop

                                       - go to record number $index

                                       - duplicate record

                                       - exit loop if $index = $limit

                                       - $index = $index + 1

                                    - end loop

                                     

                                    It might take many milliseconds, but it should work.

                                    1 2 Previous Next