Wim Decorte

FireFox is not a supported browser for the FMS admin console, not for those older versions. The output from the fmsadmin command line shows that the command is recognized, so you're in the right spot to run it. I don't recall whether FMS 11 supported the "restart adminserver" command so you may have to do "fmsadmin help commands" to get a list and get help on individual commands. If you installed Java manually then you likely broke a lot of stuff. FMS has a very narrow window of supported Java versions, see the list here: https://support.claris.com/s/article/FileMaker-Server-and-Java-Overview-1503693052471?language=en_US FMS11 is so old that it is not even listed anymore but it does show that your Java 8 is not compatible. Uninstalling Java is a pain but you'll have to start there if you hope to bring FMS11 back. Your best bet is to completely stop all FMS processes (what operating system is this?), upgrade the files from the .fp7 file format to .fmp12, get a license for FM19 (basic license will get you 5 users and server) and just install the server fresh on a supported OS. FMS 11 is so old that it will prove to be difficult to run it on any modern OS and hardware and same with the FM11 clients.

in the older versions of FMS, the 'fmsadmin' executable is not on the known path. So navigate your command line window to where it is (usually something like c:\program files\filemaker\filemaker server\database server\) and execute it from there

The postman failure indicates that the backend is not set up correctly. Which provider would you want to get working? Auth0 or KeyCloak?

Since there is no Advisor table nor a Student table, there are no primary keys for those entities. The design choice here is to go with a people table called Everyone and the primary key for that table is the field "PrimaryKey" The advisor or student role is just an attribute of the Everyone entity, expressed by setting the Advisor ID/Student ID in Everyone and creating a record in the JOIN table to link up someone as advisor with someone as a student. This is just one of a few ways you can design this.

I don't think that FM is the right platform for you... if you use FMP (which is a full-featured fat client and semi-host) only to make the FM file available through its APIs - but completely bypassing the features built into the client itself - then you'd be much better off dumping the data to MySQL and using your PHP skills to build all the front-ends you want. If you are proficient in HTML5 and JavaScript you can use the new features in 19 to very effectively supplement any data visuals you want AND get all the benefits of the clients. But if you are jumping from 5 to 14 (and not 19) for monetary reasons then that would just reinforce my recommendation: stop using FM. FM14 is getting to be really old and you're bound to run into OS compatibility issues as time goes by.

Not really... if you have the file local and you are the only user, why not just open it in FileMaker Pro? Why the reference to a browser?

Can you expand on this: Do you mean using FM's Webdirect to allow other people access to your file?

For (A) - What is the purpose of the STATUS table? Is that to record when the status changes, for a particular patient? In that case you don't need a join table between STATUS and PATIENTS. For (B): look for the nouns in that sentence. Feels like you need a table called INTERACTIONS. Or perhaps you have another table already tagged for that but call it differently? You may be overthinking the "join table" bit. You'd typically only need a join table to accommodate a many-to-many relationship. For instance if one patient can have multiple tests but one test covers multiple patients (unlikely - but you get the drift). The only place in your narrative where I see a join table potentially are the interactions, if one interaction is with multiple patients at the same time. Barring that; all you have are normal relationships with no need for join tables. (it doesn't help of course that in relational database speak and especially in the SQL language, a JOIN is just another word for a relationship). In FM speak it carries that special meaning of many-to-many, where in SQL it does not. In general, when you need a join table it is to cover one specific type of relationship. Like "patients involved in a visit". So don't think about it too generically like "each Buoy gets its own join table", think of it more simply in terms of what you want to cover.

Probably because you are using the wrong endpoint. To set globals you have to call the explicit globals endpoint. See the one listed in my Postman screenshot. Does yours look like that?

Answered on community.claris.com... Download the VC++ redistributable from Microsoft and install that one first. Then install FMS.

This is a classic example of ideally getting those numbers from the most current state after whatever transactions that move the needle have posted. There really is no reason why this would have to be recalculated over and over again every time you need the numbers. It's not scalable as the foundation for a web app. It's not even scalable as a FM-only mechanism. Inventory is another good example and basically anything to do with accounting (AR, AP... which yours shares a lot of similarities with).

The one thing that is odd about your description of the sequence of API calls is the 'find'. Given that you set a global and that global needs to fire some calcs, you don't need to find a particular record. Any record of the context where the global lives will do since the global has the same value across all records and thus all calcs based on that should have the same value. Unless there are other dependencies in your calc that do depend on what record the user is on. If that is the case then that is probably where it fails and the global is just a red herring. But a solution that produces unpredictable responses is a clear sign of being in need of a thorough cleanup...

The Data API works as expected in this case. This setup, with a global field that triggers a relationship to another table, and a calculation field that uses that relationship: I log in with the Data API, get a token then make the call to update that 'number_gn' global: If then make another call (using the same token obviously, to stay within the same session ) to get the records from the _GLO table (where the calculation is) I get the proper value to show up If I make another call to change the global and then another call to get the _GLO record, I get the properly updated value for 'list_c'. So something in your setup isn't triggering the calculation like you think it does.

I already gave it a few replies back in this thread: use all the system logs available to trace any and all activity on those boxes - the clues will be there. Since this is a fairly specific time-frame and happens to all of the servers there it has to be some environmental thing. Or a piece of extra software that gets installed by default on all machines. Could be as simple as the control software for the UPSes. This behavior is not induced by FMS, otherwise it would happen to a lot more servers everywhere and it isn't. So it is something specific to this deployment.

We run hundreds of servers: when you turn it off it stays off.