AnsweredAssumed Answered

Filemaker Server 17 ghost connections

Question asked by NorbertWeiss_1 on Aug 2, 2018
Latest reply on Aug 8, 2018 by NorbertWeiss_1

We've been using FMS17 for some weeks now. Since version 17 we encounter ghost connections from Filemaker GO 17 clients on 2018 iPads: The same device shows up in Filemaker Server Admin Console several times. This can cause running out of licenses, so iPad clients are no longer able to connect to Filemaker Server. Admin Console connections looks like this:

FMS17_ghost.jpg

A single Filemaker Pro Advanced client also connects to this FMS via Ethernet without any ghost connection problems. There are only ghost connections from iPad/Filemaker GO (Wifi) clients. Connection timeout on FMS is set to 15 Minutes. "fmreauthenticate10" privilege has been set in FMS databases, but didn't help either.

 

Filemaker support couldn't help. They say it may have to do with "our solution in case our solution uses references to more than a single FM database" (which is weird, since this would be a standard use of Filemaker AND our solution/FM databases don't use any references to other FM databases).

 

Our solutions are quite simple:
Several "stand alone" Filemaker databases (not using any references to other FM databases), most of them using ESS to an SQL Server, mostly used on iPads for mobile warehouse mgt and shipping.

 

Wifi connection to iPads CAN vary of course, since the warehouse guys are moving with their iPads in our big warehouse. However, even in case a Wifi connection is bad, Filemaker clients and server should be able to manage this. Filemaker Server should be able to recognize when multiple connections for the same client exists, as it shows in FMS Admin console itself. I think, that's what a "connection timeout" FMS uses should be used for - at least.

 

Also, the Filemaker GO clients NEVER manage to reconnect to a database: when FM GO connected to a database on FMS is brought to the background (e.g. by using the Home-Button on iPad), Filemaker GO 17 fails at a 100% rate to reconnect to the opened database when FM GO is brought to the foreground again. This is also a quite unusual behaviour.

 

Any ideas?

Outcomes