Random Unresponsiveness

Are you using FileMaker 11 or 11v2. Don't see anything specifically listed for your issue with the download notes, but it's free and if it fixes it problem solved. If not, you're no worse off.

We are getting random stops in FM11 - are you using Server 11? If so what Operating System is it on?

Dave

Robert Nakama:

Thank you for your posts.

Since this is happening on two different machines, are you accessing a shared file either from another client or hosted by FileMaker Server?  I know you said this happens randomly, but do you recall what you were doing just prior to the crash?  That is, did you run a script?  Did you run a report?  Did you perform a Replace?  Did you make a backup copy?  Does this usually occur when using the same database file?  If you don't recall, please write down what you can remember the next time this occurs.

Also, write down your current environment at the time.  That is, what other applications are you running.

TSGal
FileMaker, Inc.

I found what it was, complicated but stick with me. I hope this helps anyone who gets similar issues with FM11 server compared to FM8S.

I am still unsure what has altered in FM11S, however it seems to center around the processing of global fields. We had a setup that showed activities per client based on clientid. Simple enough, however some clients ended up over the years having 100's of activities, so a way was required to filter these by date. So within the client db two global fields where created (startdate and enddate), each activity had a date stamp and so the relationship was enhanced between the two tables to take into account the dates.

This worked fine for many years in FM8S and 8 Client. The next added complexity to the system is that about 50% of users that login, login with a user that has record access locked. In other words depending who they log in as - depends on what set of client records they can view and search within. This works based on their User ID (global field) and the owner ID within each record. Again this worked fine until we upgraded to FM11S and FM11C.

Symptons started with large delays in the system when locked down users logged in, this was alway a minor problem in FM8S - as due to the global field the calulation to work out the clients they can view is done on the server. Even though FMS is multi threaded, these calculations appear to tie FMS in knots until its finished all other users get stuck on white screens etc. In FM11 the logon problem became worse, with the delays taking longer to clear each time. However the major problem we suddenly got when we moved to FM11S was that deleting records made the system pause for 10-30 seconds. I could delete a record in any of the 40 odd tables - and if that table had any relationship with the main client db then the pause would happen. The obvious thing to look at here would be the cascading effect of deleting child records - but I can assure you that was not the issue here.

Deleting records simply brought the system to its knees, within the FMS console all clients had a wait time of about a million until it cleared and every one could use it again. This deleting problem, and the logon problem, with 140 users, just pretty much made the system unusable for most of the day.

I spent 2 weeks trying in vain to cure the problem, even upgraded the server to a much more beefy setup, with no joy. Then in desperation one day I simply removed the date part of the relationship described at the start. So clients now listed all activities without any filtering. Instantly the problems all went away. I can delete to my hearts content, and logging in users cause hardly any effect on the system.

To make it even weirder, the system has a todo area, so all users have things they are todo - these are bascially activities that are not set as 'done' for that userid. This relationship also has global fields for dates so the portal can be filtered - but of course it is not linked to the clients it is linked to your userid so you only see your 'todos'. And that is where I think the bug if you want to call it that lies. The fact that FMS is calculating the filtered acitivities for clients using global fields that are also record locked based on a global field just brings FMS11 to its knees. It cannot appear to cope with that level of server side processing.

So for the moment the fix is simple, removed the relationship that is attached to the record locked table that uses global fields. Problem solved - however I still feel this is not an unusual setup, maybe more complex than most, but its all within the capability of FM so it should handle it a bit better.

Id love for a more senior FM employee developer to get in touch so I can detail this in person, but have tried the phone avenues with FM and just get the standard check list read out to me. (yes FMS is running, no the server is not doing anything else...)

If this just helps one person then brilliant, as this almost brought me to tears!

Dave

Its a shame no one at Filemaker ever contacted me about this, but its clear that this fault must have been noticed. The FMS 11 v3 update has the line 

“Addressed an issue where FileMaker Server becomes unresponsive after a client performs a query that requires the server to request the client’s global fields.”

which was our problem exactly. 

So no need for a work around now, you can 'hopefully' use global fields correctly in relationships in FMS11...

Dave