1 of 1 people found this helpful
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
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).
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.
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."
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.
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.
Happens all the time to me.