Local Development using FileMaker Server

Whether you're a hobbyist developer or a full-time professional, it's important to make sure your development environment is both stable and reliable. Unless you're in the process of learning a new environment, not that many developers are keen to spending a bunch of time re-configuring their development environment.

The worst feeling in the world, while developing, is one of instability. Having that looming fear that your application or file may crash at any time is not a happy place. It's like you're constantly looking over your shoulder waiting for the next FileMaker crash. For FileMaker development, the solution to this problem is to always develop using FileMaker Server.

When FileMaker Server is within your development environment it provides crash protection, automated backups and other learning benefits which you simply won't get if you only upload your FileMaker file to a host and simply work that way. If you're still developing locally with just a copy of FileMaker Pro Advanced then this video should be especially appealing.

Also, if you're a developer on-the-go and you can't be tied to a local network, and may not have WAN access, then running a local FileMaker Server is a great solution. One possible issue is that FileMaker Server has be structured for a production environment and not for a development. You can, however, with a few setup changes, make your local development machine use FileMaker Server in order to facilitate the ideal development environment.

Comments

Hi,

When I upload a brand new file to FMServer, you also get the recoverd.log file.
With regards to the VM. You don't have the problems of some OS update interfering with your installation of FMServer as is has with java-updates and other in the past.

So, I am running it in Parallels.

Yep, when you upload a FileMaker file to server it does a verification check. After the upload, the server has a copy of the file you uploaded - not the local file. Recover.log is not fun to see when you know the file had crashed locally.

Also, it's true, with a VM you get a completely isolated OS. But that comes with the burden of it's file size and resource use.

Yes, there is the potential of Java updates causing issues if you run a separate JDK. I personally do, but I've not had too many issues over time. The key is knowing how things work when FileMaker server is installed and that's part of the goal of this video.

If you like running FileMaker Server within a VM, then that's the best method for you. I've done that one too. :)

-- Matt Petrowsky - ISO FileMaker Magazine Editor

You mention about a tool instead of doing the modifications, etc., via the terminal. The tool you want is called LaunchConrol from soma zone at http://www.soma-zone.com/LaunchControl/.

You can edit the fms plist right in the tool to turn off the auto-start of the FM server. The best part is that you can add this daemon to a feature called "QuickLaunch". This will place an icon in the menu bar where you can see the status of the FM server as well as start and stop it. See the screenshot of this on the referenced web page.

Hope this helps.

Just my opinion... I've been developing in Filemaker for many years and for most of that time I have successfully and happily developed "locally". Over all those years, I can hardly recall the rare occasion that Filemaker has crashed and if it has, the even more rare occasion the file has been corrupted. In fact the only time I tested and found a file corrupted, occurred with somebody else's file (and then I subsequently discovered that file was "faulty" when I first received it).

Should Filemaker crash - due to a power outage say, or a runaway script, and I need to force quit, I will always check the file using the Recover command. If the Report doesn't show an absolutely clean result, I will use a recent Backup.

Backing up in Filemaker Pro/Advanced could not be simpler... There's the "Save a Copy" command. There's no delay (no pausing involved). When developing, I make frequent backups, not just for safety, but because it gives me a reversion trail should I go down a path which becomes over-complicated (or not a good move). By having many "versions" from frequent backups, I can step back in time and review or compare etc. etc.

As a matter of safety, before venturing out on any potentially risky script or crazy idea, I will test on a throw-away (scratch) file and prove something there (like a test-bed). This the beauty of Filemaker's Save a Copy command... Prototyping and testing. These Backup copies are readily available (easy to find), unlike Servers method of poking down through a complex web of paths to find the one you want.

One can also drown in sea of backup copies, and that's where I appreciate the ease with which local copies (when no longer of value), can be found and put in the trash.

As for automatic backups, I have occasionally used Filemaker's buit in onTimer to create a schedule; the simplest being a daily backup (if the file is left open) and a backup that runs on last window close. It's not hard to do.

I prefer NOT to use Filemaker Server for development. I do have the Developer version at my ready here, and have used it from time to time, but consider it more trouble than it's worth. In fact you demonstrate some of the reasons why... I never have to concern myself about IP addresses (if they change), or starting or stopping it, or computer sleeps. I know it's good to be educated and aware of the power of command line tools, but it's an extra thing to "do right". I never have to think about any potential "connection" concerns because my file is directly open In Filemaker. It also runs faster.

On the other hand, I do occasionally use Server as a proofing tool, because it is necessary to prove a file works as expected when subsequently hosted.

I just worry that you might be scaring people (or making them feel less diligent or compliant or guilty) if they don't exclusively use Filemaker Server for development. Incidentally, regarding your mention of crash protection/prevention, a power glitch will hit FMServer just the same as it will Desktop FMPAdvanced. If a file is being written to just at that critical moment - it's bad news, regardless. It is true that Server won't hang when a script on local desktop goes loopy, but there have been cases where badly designed PSOS scripts have compromised and slowed Server too.

There are a lot of extra things to prepare for if you want to make Server a permanent part of your work environment - things that aren't necessary if you don't use Server for development. I would rather focus my resources directly on my job.

To be fair to you, I found your video to be very informative in the way you demonstrate how to install and configure FM Server. It is very clear.

It's a pity that you couple it with the notion that it's almost one's duty to use it if you want to develop in a safe and reliable environment.

Regards
Ralph

RalphLearmont

Hi Matt - I appreciate this video and have set up a local copy of FMS on a server on my LAN. It is definitely handy for testing how things perform when hosted, and I can see how the enhanced stability is a good thing. One thing though that gets more inconvenient is version control. When developing with FMPA, whenever I make a significant change, I will run a script to Flush Cache to DIsk and then do a commit to my SVN repository. (I've read that I shouldn't do this while a file is open in FMP, but I haven't had any problems. I'm the only one using it so there's no possibility that any activity is going on). I can comment my commit with whatever changes have been made to make it easy to go back if necessary.
With server, I don't see a good way to do this. I'd have to close the file, download a copy, commit it, and reopen the file on Server.
As far as good development practice, I would hate to stop doing regular commits with descriptions.
Any thoughts on this issue?
Thanks!