How exactly is the data being entered? Via a FileMaker Client? Or though data entered in someone's web browser?
I assume a FileMaker client, but let's be sure.
And the people that are not seeing the update, are they using FileMaker or a web browser in their attempt to view this data?
Through the FileMaker Client in both cases. The web interface is mostly used to let visiting researchers view data.
Data saved to the database should be available to all users in a matter of seconds.
Since you've indicated that days can go by before others see the updated data, something is wrong with the design of your database.
There are several possible ways this might happen, one is that the people not seeing the updated data are looking at fields that reference the new data via auto-enter field options that refer to this data from the context of a related table. In such cases, the data shown in the field with the looked up value or auto-enter calculation will not automatically update when the data referenced in a different record or table is modified.
I can see why you might think that. Certainly, if I heard someone else describe this problem, I would assume that database design was the issue.
However, this is an issue that applies to all fields, in every table I have tested. And they are simply... fields. No calcs, no lookups, no dependencies, no peering at them from a related table. Fields.
After this issue was reported, I ran tests on two machines (using one directly, remoting into the other.) And I can confirm that changed data is simply not getting sent to the other workstations, unless users on both ends do something drastic, like shuttling from one end of the table to the other to force a data exchange with the server.
Hence, the server is not doing its job for some reason. I have made some configuration tweaks, such as booting users after 12 hours of inactivity, and added "Commit record" trigger scripts to the most critical fields. (This does seem to help, but should NOT be necessary.) We shall see if performance improves.
So... I gather nobody else has reported this problem?
No one has and I've been using FileMaker for a very long time.
It really sounds like you have more than one copy of the same database and your different workstations are not accessing the same copy of the file.
How are you hosting the file?
How are you accessing the hosted file? Using Open Remote?
And there are design issues that can create confusion as to whether you are actually looking at the same data--such as having records with duplicate ID's. You modify a record with ID = 200345 and when you use a different workstation to look at a record with 200345, but it's actually a different record with the same ID, you won't see the changes as you are not looking at the same record even though it looks like you are. You may want to perform a find for duplicates on your tables followed by a sort to group duplicate values together to see what you get when you do that.
By duplicate ID's, I assume you mean the internal record ID assigned by FileMaker? I can see it would cause issues if those somehow became duplicated. But then I would assume that the problem would appear only in certain tables, for certain records. I'll attach a calc to the record ID and check for dupes, but I honestly don't expect to find any, since the issue appears to be system-wide.
Some background: our current FileMaker 13 application is a totally re-built (not migrated) version of our legacy FileMaker 6 application, which in turn was based on our ultra-legacy Nutshell application. I've been building and maintaining this thing since approximately 1998.
The application contains six files, with 116 tables and a few million records. They are hosted on a virtual server. (Does that ring any warning bells? I know it made me nervous when we moved off of physical hardware.) It's a dedicated server. The web interface is hosted on a second virtual server, for a two-machine installation.
The two servers are running Windows Server 2008 R2, Enterprise Edition. (Warning bells are probably clanging wildly now, since the Enterprise Edition is not in the list of supported software. I have been assured by a FMI Systems Engineer that it should be perfectly fine, but who knows? We are at the mercy of our central IT department, which only supports the Enterprise Edition.)
Each user has a "launcher file" (a tiny FMP application) on their desktop, which connects to the hosted files on the server with Open Remote.
There is really only one copy of the data files. Believe me, I checked.
For what it's worth, we have had persistent peculiarities with our FileMaker server machine, even before it went virtual. I have not been able to apply server updaters since FileMaker 7. The .exe files simply don't run. The Systems Engineer I mentioned earlier told me how to run the updaters by invoking the .msi files directly. But that is no longer supported, and the only way I can currently update FileMaker Server is to uninstall the product and reinstall it from refreshed code. I mention this because I think it hints at some incompatibility with the server operating system. Could the installer be detecting an unsupported edition, and simply fail? I have no idea, but it would be nice if it threw an error message to let us know what the issue is.
I'll keep working on this. As I mentioned earlier, attaching a "Commit record" trigger to the critical field (a numeric field, which appears on the layout as a checkbox) does seem to force the changes through. But it's an ugly fix, and I hate to be dependent on it.
At the moment, things seem to be working properly. Perhaps a few server re-boots, increasing available disk space and getting rid of the zombie users have cleaned things up. Cross fingers, knock wood.
By duplicate ID's, I assume you mean the internal record ID assigned by FileMaker?
No, I mean ID's set up in a field defined by you to auto-enter an ID value such as an auto-entered serial number. If, at any time, you imported data from one copy of your file into a different copy--such as part of an update or to recover data from a damaged file, it's quite easy to end up with records with duplicate serial numbers if the proper steps to avoid this are not taken as part of the import.
Your engineer may have not given you good advice about your choice of Server OS. I don't have the info at my finger tips, but TSGal, a tech support person at FileMaker Inc. over in Report an Issue, has repeatedly warned against using a particular version of the windows server software as it was not certified for FileMaker Server 13 and "had a lot of issues during testing". This sounds like the version you are using, but don't take my word for it, search through Report an issue for references to this version and check for posts by this person to see if this is the case.
The fact that Commit Records corrects the problem is very informative. Date entered by any given client will not be accessible to other clients until the data is committed. Normally, this is not a major issue as there are many, many normal user interactions that automatically commit the data with no need to force the issue. So it sounds like there is some peculiarity to the design of your database that makes it easy for a user to add or modify data and leave it uncommitted for very long periods of time...