Wim Decorte

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) f

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 patie

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 p

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 anot

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.

The link to the community page doesn't work; but you can most certainly completely disable the data restoration in 18 and 19.0. In fact, 19.0 installs with the feature turned off by default. The feature is gone in 19.1. Because it is instructed to do so. There is most definitely something on your machine that is triggering a shutdown. And moving up to 19 is probably not going to solve it since this is a non-FMS event. Use all the logs available to you through the macOS console app and go through them with a fine comb. Tedious, and easy to get impatient with it, but the clues will

This seems to be the key here, how do those fields with values >0 get their value? Some sort of calculation that involves the global field? Global fields do keep their value for the duration of the token's session; if my suspicion is correct you are running into a calculation refresh issue. Which I would tackle at the root by looking at how not to have to calcs and get the desired value another way.

If you can open the file, it is as simple as exporting to the excel or CSV format...