Filmaker Server 14 is NOT a robust product

Discussion created by Vincent_L on Jan 7, 2016
Latest reply on Jan 31, 2016 by Vincent_L



I'm sorry but truth to be told filemaker server 14 is not robust.

Here's what just happened to me (again)


I changed 10 field declarations and TO in my main table, then I clicked ok to save the changes.

Yes I was developing live (I know that's not recommended, but I'm a in house dev, I have no choice, and since Filemaker doesn't provide any real data separation model… Nad also, as the feature exists it should work)

Of course many users were using the file. But also a scheduled server side script.


I do this daily, but this time, maybe there were more changes, maybe the server side script came into play, but still after 10 minutes the changes weren't committed and people started to complain they couldn't do anything.


But the fmserver process what only unit 0,1% and my fas client also. So of course if no-one is churning out CPU time, it could get long. I kept patient for 20 minutes and then decided to act. And now it's the par that show the non robustness of FMS


I decided to disconnect the scheduled server side processing script : with the GUI : no reaction from the GUI, then in command line.

I tried 10 times in command line. No go


I then decided to disconnect all client one by one to just be able to keep my client (which does the schema mod), practically no reaction. But on insisting, some clients got disconnected after a long time. The webdamin GUI sin't refresh well, as client disconnect in command line stil appeared in GUI.


The lack of proper web admin GUI synchronization is a well documented issue, that is stil not addressed by the way.


So I kept trying disconnect for 30 minutes. 5 users including the server side script and my connection remained.


Since nothing changed for minutes, and CPU on client and server still idling, I decided to kill the fmased process. I thought it would disconnect the  server side script client. Wrong : even thought fmased was killed, the server side script client was reported to be connected (with GUI and command line).


Therefore I finally decided to disconnect my client. Which worked albeit very slowly.

Then I decided to reboot everything, so with command line I first close all files, it worked. But even though all the file were closed according to command line, GUI was still showing the server side client connected and 10 files not closed.


Also, only 2 files were reported closed by the server log


I decided to stop the server, with GUI, the "power button" did grayed out, but then nothing happened, refreshing status page, server still on.


I then used command line, the closing command never ended


I finally rebooted the mac.


- Why did my modification took so much time to apply, WITH NO CPU USAGE, nor on server or client.

- Why scheduled server side script client disconnecting didn't work

- Why client disconnecting took so much time WITH NO CPU USAGE

- Why scheduled server side script client did not disconnect when I killed fmased

- Why the webamin GUI is such out of sync

- Why the log didn't reported all the file closing

So those problems and questions highlight the lack of robustness. The server should be able to kill anyone immediately, and the GUI should be in sync.


If schema modification can cause such problems if server side script is running on same table, then, the client should tell the dev "hey by the way a server side script is using your files, it will take ages to register your changes, do you want me to apply the mode once the server side script is done ?)


Thanks for improving this