You'll need to document your set up. What version of server and client are you using? What kind of clients? Windows, Mac, iOS, Webrowser?...
FM Server 14 v18.104.22.168 Running on Windows 7 Professional Service pack 1
Clients various versions of FM Pro 14 client on Mac.
Well that rules out possible issues due to FMP 15's more extensive use of temporary files...
And this is happening to multiple clients on different machines and versions?
That points at your server and how it communicates with the clients.
Has there been any changes to client or server machines that happened about the same time that this issue appeared for the first time?
Next thing I'd do is check the logs and server stats to see if anything looks out of the ordinary. That's about the limit of what I can suggest, but perhaps someone else will have a suggestion.
You can also use Report an Issue to report this as a possible bug in order to bring it to the attention of some people that actually work for FileMaker and they may have some ideas that we don't.
We haven't made any changes. Maybe we need to do a server restart.
We did a server reboot last night. So far today we haven't had any complaints. I've asked around and everything seems to be working properly.
Here's to hoping that's the end of it.
Did you ever see this problem again?
We have massive problems with this. One client does update on a record and some other clients can't see it until the client is restarted. We have no clear pattern, but the issue is more frequent if we have a fm14 server and fm13 clients. Less frequent, but not all gone with 14 clients. We are now trying with fms15 with fmp14 clients. (no result yet)
Our solutions is very server intense, but the server is not maxed out more than a few seconds from time to time. I was thinking in the line of that the server did not have enough time to properly serve all data to every client in a timely manner, but that does not seem to be the case.
I now think that it could be client related. Maybe the client has an old cache of the record, that did not get the proper "This record is updated - fetch it again"-order, because this rarely happens to newly created records. It could very vell be a server issue also if the cached record did not get proper update action of course.
We have mostly 32-bit clients which could be an issue. (We use a plugin that do not support 64-bit version of FM. We are in the process of rebuilding our system to not use that plugin.)
Rebooting the server seems to have solved the problem. I haven't had any reports of it reoccurring since.
I have no idea what caused the problem, the server didn't seem to be overloaded at the time. No one was reporting performance issues, just incorrect data. You'd assume if it was overloaded it would eventually update the incorrect data but it required closing the clients and logging in again. The server just seemed to have gone into some weird state where it wasn't pushing out updates.
Hopefully a reboot will solve your problems to.
Remember to disconnect the clients, and manually close all the files before rebooting.
We've seen this as well - about once or twice a week on a server with as many as 160 client connections. We are on FM Server 15, mostly FM Pro 14 clients, all Windows, all clients 32-bit. Our advice to users who are seeing this is to restart the FileMaker client, which usually solves the problem. Refresh Window/flush cached join results does nothing in these situations.
It hasn't happened often enough to cause major problems, but any amount of data infidelity is fairly concerning. Hoping that once everyone is running 15 (which won't be long now), the problem will go away. Updating 160+ users to 64-bit is not in our short-term plans, so hopefully it's not that.
"Glad" we´re not alone. We will investigate further, but it seems like the client has a cache for data via a relation, but if we do a search (works with ExecuteSQL) for the same thing as the relation - we get the correct data.
Do you by any chance have a large solution with interface/gui files separated from data files?
We do have a real issue with this, since we use a lot of serverside scripting and "perform on server". Stuff done that way will not always be updated to clients in a timely manner. Likewise with wpe calls to scripts that change records - clients do not always see those changes.
Restart of server does not solve the problem - not for a very long time anyway.
[EDIT] This might be a problem for WAN clients. Not sure if this happens for LAN clients yet.
It looks like you have a different problem than I did.
Ours is a large miss mash of files (>100), some of which were created in FileMaker II. We are not separating the gui from the data.
The symptoms were slightly different as well. For example one user would create new records but for other users the record count in the tool bar would not increase. The same if a user changed data in a record. Other users looking at that same record in the same layout would not see the change, even after changing records and coming back. So ours applied to the parent table as well as related ones.
Again a simple reboot seems to have solved it.
Ok, so different solution, but, the problem does look similar. I did some more testing and indeed - as the server does its Perform on Server, another client active in a tableview of the affected table, does not see any new records, until a Search is performed. (It does not even see the record count change)
Are your clients on LAN or on WAN?
We are in the process of testing this on LAN, with 15 server and 15 clients.
Worth to know, is that this problem was introduced with FMS 14. FMS 13 did not have this problem.