7 Replies Latest reply on Nov 14, 2016 2:32 PM by Mike_Mitchell

    FileMaker Server question


      Hi all,


      I'm building a solution for my business and have a quick question.  There are 4 users in my company for this solution. The system will have a 'desktop file' which has no actual tables, only 'shadow' tables which are in the 'server file'.  In the past I've put a copy of the desktop file on each machine. This file is linked to the 'server' file. We haven't used FM Server for this in the past as there have only been a couple of users and there isn't much data involved.


      I'm now looking at using FM Server (probably on a Cloud or hosted service).  My question is:


      Do I still use a 'desktop' file which is actually on each machine or can I put a link to a hosted 'desktop file'? This would connect to the hosted 'server' file which has all of the data.  If I can put a copy of the 'desktop' file on the hosted server that would be easier as I can update that file and all users would then get all of the new functionality immediately.


      Hope that makes sense.





        • 1. Re: FileMaker Server question

          Hi Jack,


          Traditionally for a remote server hosted file, you normally just make a "shortcut" .fmp12 file. This database will:


          1) Run an OnFirstWindowOpen script trigger

          2) with a script that has two steps, "Open File" and "Close File"

          3) Open File will open the remote file off of your hosted server.

          4) Close File (current file) will close the shortcut file itself.


          Or you can forego the shortcut file completely and just train your users how to use the File > Open Remote dialog to open the hosted files. Once opened, the remote file will appear in their "Open Recent" menu for future use.


          You can also add the remote host to your "favorite hosts" for future reference.

          1 of 1 people found this helpful
          • 2. Re: FileMaker Server question

            To build on Mike's suggestion, if you're using a separation model (one file for interface and another for data, for example), you can put all the files on the server and just have the users open the interface. This does make maintenance easier (only one file to maintain, on the server).

            1 of 1 people found this helpful
            • 3. Re: FileMaker Server question

              In theory, you are supposed to get faster performance with the UI file local to each client machine as the Layout Design does not have to be downloaded from server to client. In practice, few find much improvement in performance--probably because all that layout info is persisting in a temp file on the client anyway, and all those extra copies make it a major hassle anytime you need to modify the design of that UI File as you have to get those copies out to each user and then get them to use it in place of the older copy.

              • 4. Re: FileMaker Server question

                In practice, we have found that users reported less problems when using a local UI file with a remote data file. We found that there are a variety of small benefits that provided users with a much better experience overall.


                One of the benefits that surprised us was the concept of ownership. We distributed the file via a web download which is simple for everyone. When we were onsite with users it was apparent that there is a big difference in the mind of the user between having a file on their own machine and logging into a remote file. Explaining that all the data was stored remotely did not change their mind. They had "their file on their machine".


                The next big difference was that the local UI file displays the UI immediately and the data loads as quickly as it can. In a remote system, there is a delay as the layout is loaded for the first time. Depending on network speeds, memory and UI design, this can interfere. Any lag in response between the user action (mouse click) and the display of the UI was negative. Users would click a button repeatedly ( click-frenzy ) and report that it was necessary to make the system work. They believed that it was the final mouse-click that worked, not the first. If there were any buttons in the same location on the new screen then that button could be clicked, initiating an unwanted action and creating a greater sense that the system didn't work.


                Users were very happy to wait while data loaded, provided they could see the user interface. If the screen changed immediately but the fields took a moment to display that was OK. The feedback was that the split system with the local UI "worked better."

                • 5. Re: FileMaker Server question

                  The biggest problem I've seen with the local UI file is when it loses connection to the server. What often happens is users who don't know any better, when prompted for the file, simply point it back to itself. This screws up the file pointers and then you have to repair it again. The concept of ownership only makes it worse, because they think the database is loaded on their local machine and don't understand that there's a remote file involved.


                  All that said, each experience will be different, depending on the user base. Do what works best for your users.

                  • 6. Re: FileMaker Server question

                    We had a help desk handling front line issues, so it could have happened, but we didn't get that problem reported back to us.

                    • 7. Re: FileMaker Server question

                      Happens all the time to me.