Hosted Solution Development
FileMaker seems like such an easy software solution. You simply craft your solution and open the file to start hosting it to peers on the same network. If you're wise, you use a copy of FileMaker server and take advantage of backups and server side scripts. This is especially important for your data, right? It's your data that's important. The user interface is simply a representation of that data.
Often, it's only when things start to bog down that attention is paid to performance and making things as optimized as possible. Fortunately, FileMaker client provides a very nice method for connecting to other FileMaker files - via the network.
The method of really taking advantage of client computing power is to put the Interface file there instead of on the server. Users are used to "updating" apps (even more so with the whole App Store thing). By putting the interface file on the client, you gain many advantages. A much faster perceived load time (since you can load any layout which does not show solution data until after a delay) and a number of operations which will run faster.
Your interface file can run as an Advanced stripped file and version enforcement can be managed via a script call to the Data file on FileMaker server. If simply reading this isn't exactly obvious, then watching this video should give you more insight into how the deployment model works.
Comments
Hi Matt I have been using
Hi Matt
I have been using this model since FM7 came out. It really surprised me that it was/is not used much around. A few things that I came across over the years is that you should avoid list/table views in the data file. Use it when you develop, but turn to form view when you deploy. Furthermore you should remove all fields from layouts in the data file except from a few id fields. Why ? Filemaker will calculate and try to send data over the network for the layouts, eventhough the file window is not shown. Just by doing that, you speed up performance a lot, which really matters on WAN.
Back in the FM7 days, my clients used the solution from airplane, where they had very slow connections.
I really miss the part where you tell how to do the "woodoo" with downloading a new interface file to the users desktop and switch thoose. Users are more and more expecting that you could update just like you do with e.g. Transmit, RapidWeaver and such apps, where the app itself downloads the update, "overwrite" the app and reopen it.
Fellow developers has been very sceptical about this deployment model as they though it was to difficult to deploy to hundreds of users.
Let's see how you solve this in your Theme Studio and can you show a way to download->Update->reopen the interface file ?
Great feedback
Hey, nice feedback on the list/table views. I've not tested this myself thoroughly but I think it would be worthy of testing. Unfortunately, for me, I don't have a solution where multiple connections over the WAN are being mad on a routine basis.
If anyone does and is willing to test that would be great.
Regarding the self-updating process. I shot a second video about how I'm doing it with the Theme Studio and that one will be posted this week.
-- Matt Petrowsky - ISO FileMaker Magazine Editor
Consider that Filemaker is
Consider that Filemaker is actually opening the file over the network. That is why we should strip down everything possibly.
Over time your datafile will grow in size and the result will be less performance speed.
That is one very good reason to consider seperating data file into 2 or 3 files, depending on the content and estimated number of records. If you e.g. have a table where you store images or files, it should be in a seperate data file. (and there are other reasons to that particular example)
This behaviour is actually one of the downsides with Filemaker. Other databases works the way that the interface sends a request to the database, which in turn returns a result. This way only the requested data gets transfered. Filemaker is kind of sending everything so it is "ready"....
Let's hope that FM12 or FM13 will do something about this.... We got new format with fp3 then with fp5 and finally with fp7. It is now about 7 years ago we got Filemaker 7 which revoulutionized the FM world..... maybe its about time for a new revolution in the Filemaker world...??? (2011 seems to be the year of revolutions anyway....)
I forgot to comment on your
I forgot to comment on your recommendation about using a domain name instead of an IP address.
While this seems to be a very good idea as your solution will continue to function if the IP address changes, it is not in real world.
The reason is that everytime Filemaker needs to get data from the data file, it uses the ESS path. So for each block of data, Filemaker ask a dns server, which IP address it should connect to. And then it connects to the IP address in order to get data.
In all my testings through the years I have found that it does matter if you do this. The solution performance will be much better if you use the IP address instead. Without knowing Filemaker under the hood, my findings is that Filemaker will need to lookup the ip address to the server each time you e.g. switch from one record to another. It would function if Filemaker did store the ip address the first time i connects to the server.
To get around this lookup issue you could edit the host file as you show. However, do this on hundreds of client computers/iPads/iPhones....??? no, that is not an option.
In my solutions I use the IP address as the first ESS path to the datafile. Then I have specified a domain name as a "fall-back" path, should the IP address change. In the past 6 years the IP adress has only changed 2 times for one of my clients so it has never been an issue to use the IP address.
Hmnnnn, something to test
Well, that would just be bad programming if FileMaker is doing a DNS lookup on each record load. I tend to give FileMaker credit for things that are just assumed to be good practice. If caching an IP address after a DNS resolution is made is NOT something they are doing, then I would expect to get a VERY GOOD justification for it.
Within one session, an IP address would rarely ever change. So it would make sense to use the same IP once the initial resolution was made. The way to test this would be to run your own copy of Bind locally and watch the DNS log as you navigate records.
tail -f /var/log/named/bind.log
Would watch the log. I don't have the time to do this test right now but it would be good to get some verification if this is the case. Anyone reading this running their own local DNS? I'll have to find out if I can get one running easily via macports.
Thanks for the feedback Claus!
-- Matt Petrowsky - ISO FileMaker Magazine Editor
I do not say that Filemaker
I do not say that Filemaker is not using best practice. However, my testing showed a very big difference when using domain name vs. the public IP address. We had users on slow and unstable connections and it was very clear to see the difference.
We did a lot of testings with the ESS. A large number of users was on the same subnet as the server so I defined the first IP to the LAN ip for the server. E.g. 192.168.1.2/data
then the public ip
99.88.77.66/data
An interesting observation was that if the user was outside, there was a significant delay as FM will continue to try to connect via the first address until it timeout. Then it tries the next one until it gets connection or have to give up.
So, while it worked for them when they were at the office it was a pain to connect outside.
Now I just use the public IP address as this works as fast as possibly and such address rarely change.
As an endnote to the dns. I have seen several ISP that has very slow dns servers, which result in long load time for websites and also in FM when using this scenario.