1 2 Previous Next 25 Replies Latest reply on Jul 25, 2013 6:44 AM by Mike_Mitchell

    controlling client from client

    Hudi

      This might be a shot in the dark and/or a weird question.

       

      Is there any way a client can execute a script or make a change on a different client?

       

      Scenario:

       

      I have a robot that runs an ontimer script all day looking for value in a flag field that is set by other clients. If f_import = 1 then it imports via ODBC and yada yada. The reason its doing this is so that we don't need drivers on every client.

       

      So, instead of running the script all day looking for that flag field, I was wondering if users in the same office and network could execute the script on the robot without having to keep the ontimer script running every 2 minutes looking for that flag field. Can they perhaps execute applescript?

       

       

      Its worth a try I figure.

       

      Thanks!

        • 1. Re: controlling client from client
          LyndsayHowarth

          360Works RemoteScripter can trigger a script on the remote client when the value of a field changes.

           

          - Lyndsay

          1 of 1 people found this helpful
          • 2. Re: controlling client from client
            sporobolus

            on 2013-06-13 15:42 Hudi wrote

             

            So, instead of running the script all day looking for that flag field, I was wondering if users in the same office and network could execute the script on the robot without having to keep the ontimer script running every 2 minutes looking for that flag field. Can they perhaps execute applescript?

             

            yes, AppleScript supports Remote Apple Events; you have to allow it on the

            destination machine (System Preferences > Sharing); then on the source machine

            run something like this:

             

            tell application "FileMaker Pro" of machine "eppc://namefromsharingprefpane.local"
                tell document "name of your document"
                  do script "name of your script"
                end tell
            end tell
            

             

            some notes:

             

            triggering a script like this could be trouble if there is an active FMP user

            at the remote end

             

            if you have only allowed specific users Remote Apple Events access (a good

            safeguard), you'll need to add a user/password to the machine string

             

            the above should run as a Perform AppleScript script step; to run in

            AppleScript Editor you may have to wrap in "using terms from..."

            • 3. Re: controlling client from client
              Hudi

              Hi Steve,

               

              Thanks for the help.

               

              I tried a few variations of what you suggested.

               

              Running into issues though.

               

              Also, if its a hosted file, does the server need to have sharing activated?

               

              Here is what the script looks like

               

              Screen shot 2013-06-14 at 12.44.55 PM.png

               

              Errors:

              Screen shot 2013-06-14 at 12.45.08 PM.png

              • 4. Re: controlling client from client
                BarbaraCooney

                I was watching this thread to see if those more familiar with ODBC Imports would ask why you're not running them server-side? I believe it is possible, as long as the DNS are named correctly.Then you can have a server script watch the flag field.

                • 5. Re: controlling client from client
                  Hudi

                  Hi Barbara,

                   

                  Unfortunately, odbc imports can only be done from the client. What can be done, and I may need to consider this, is importing from a table occurance that is an ESS.

                   

                  You raise a good question and it really is a shame that we can't do this.

                   

                  Where I learned this: https://fmdev.filemaker.com/message/117840#117840

                  • 6. Re: controlling client from client
                    sporobolus

                    on 2013-06-14 11:51 Hudi wrote

                    I tried a few variations of what you suggested.

                     

                    Running into issues though.

                     

                    Also, if its a hosted file, does the server need to have sharing activated?

                     

                    i doubt it, but have not tried it; let us know what you conclude

                     

                    Here is what the script looks like

                     

                    i haven't done remote events in years, but when i google the error message it

                    suggests a user name password issue; it is possible that you could put in just

                    the user name, and it will ask the password the first time, offering to save it

                    in the keychain; this would be more secure than coding the password into the

                    script, e.g.

                     

                    tell application "FileMaker Pro" of machine 
                    "eppc://user@L2-Conferences-Mac-mini.local"
                    

                     

                     

                    beyond that, i think the proper document reference would be

                     

                    tell document "Start.fmp12"

                     

                    (no path, the database file must be open)

                    • 7. Re: controlling client from client
                      BarbaraCooney

                      This contradicts FM KB Article 7035, which states that ODBC imports are supported server-side.

                      • 8. Re: controlling client from client
                        Mike_Mitchell

                        Well, I'll be a monkey's uncle ...

                         

                        I just tested server-side ODBC imports. The KB article is correct. You can do this, as long as the identical DSNs are installed on both client and server.

                         

                        Note: For the Import Record script step, 32-bit DSNs / drivers are required on Windows, while 64-bit drivers are required for ESS. (Ran into that one some time back.)

                         

                        Will cross-post this to the other thread to make sure we don't have bad info floating around.

                         

                        Mike

                        • 9. Re: controlling client from client
                          FileKraft

                          if you want to tell the robot to do something from a remote client delete a record which is open in a window on the robot. when the next record loads an OnRecordLoad trigger fires and you can take it from there ..

                           

                          just watch that the window never closes and the record you can aim at from the remote client is known to the robot and the current record and the other client knows it's ID ..

                           

                          good luck ..

                           

                          (it requires at least fm10 ..)

                           

                          uli

                          1 of 1 people found this helpful
                          • 10. Re: controlling client from client
                            Hudi

                            I like that. Using script triggers.

                             

                            I was using that to open the remote file on the robot (ical event script opens a local dummy database which triggers a script the openning of the remote database)

                             

                            Had not thought to use them to trigger the import script.

                             

                            Thanks!

                            • 11. Re: controlling client from client
                              FileKraft

                              it's actually THEE solution - you can even create records on the robot for each potential client and it also works on FM GO ..

                              no plugins etc .. and you just recreate the record when it's deleted to get the record back and refire ..

                               

                              so the problem should be solved!

                              • 12. Re: controlling client from client
                                Hudi

                                It's great. so simple.

                                 

                                Question: why 'delete'? why not go to next record or anything else that will trigger the script (OnRecordLoad, OnLayoutEnter). Its a small thing but I'm just curious if that's the only way to make it work.

                                 

                                Hudi

                                • 13. Re: controlling client from client
                                  FileKraft

                                  it has to be passively aggressive: only deleting the so call triggerTheRobot record from the remote client will if it this same record is open in a window as the current record ignite the OnRecordLoad trigger thru it's disappearance there.

                                   

                                  the onRecordLoad trigger will recreate that record for the next run and now do all the desired work you have planned for the robot to do when the event occurs ..

                                  • 14. Re: controlling client from client
                                    sporobolus

                                    on 2013-06-19 10:05 FileKraft wrote

                                    if you want to tell the robot to do something from a remote client delete a record which is open in a window on the robot.

                                     

                                    interesting but abstruse; i have used the model of creating job records which

                                    the robot keeps watch for in a loop; this is not as purely event driven, but it

                                    gives you flexibility to send parameters, trigger multiple types of tasks,

                                    etc.; and the client(s) can queue up multiple job records without worrying

                                    about handling a second event trigger before the first job is finished

                                    1 2 Previous Next