ISO FileMaker Magazine

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.

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

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!