The FileMaker Go Syncing Issue

Wednesday 11th September, 2013

FileMaker developers definitely have a problem. FileMaker itself may have a problem (or is it a deliberate design flaw?) Synching between database documents on FileMaker Go, and shared databases on server, or even a client-only databases is problematic.

Synching is hard. Leaving it to 3rd party developers to provide relatively expensive, partial solutions, is in reality, we contend, no solution.

When FileMaker first introduced FileMaker Server, they also added a ‘10ip-addresses-in-a-24-hour-period’ limit on the peer-to-peer serving that had been the only sharing option with the previous client application. These days it’s down to 5 ip-addresses. Which is fine. It makes sense for them, and ensures that solutions which need a server , i.e. one with lots of users, that would be liable to corruption with a peer-to-peer, are made to use one. (In fact, one should argue that 3 ip-addresses is probably ample.)

When they introduced the licence-free, save-as-standalone option for the developer client, they disabled the network connection elements. Fine too. They should get paid for their work, and it would be insane to allow developers to create x-hundred ‘standalone’ apps that managed to act as free clients. Again, no issue there.

Would making synchronisation a server-only function move the goal-posts in terms of licence sales? Surely not. And would it make moving to FileMaker in-house a no-brainer for a large number of SMEs.

It is possible to roll-you-own synchronisation tool, we’ve done it now (using two ! different approaches), and yes there are some excellent, if expensive, 3rd party tools out there. But despite the claims to ease of integration and white-label setup, they’re quite a faff to integrate.

FileMaker need to solve the synchronisation problem. Maybe 13 (12.5?) will do that.