Jump to content

Wim Decorte

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Wim Decorte

  1. 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.
  2. 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
  3. The postman failure indicates that the backend is not set up correctly. Which provider would you want to get working? Auth0 or KeyCloak?
  4. 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.
  5. 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.
  6. 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?
  7. Can you expand on this: Do you mean using FM's Webdirect to allow other people access to your file?
  8. 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.
  9. 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?
  10. Answered on community.claris.com... Download the VC++ redistributable from Microsoft and install that one first. Then install FMS.
  11. 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).
  12. 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...
  13. 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.
  14. 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.
  15. We run hundreds of servers: when you turn it off it stays off.
  16. 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 be there.
  17. 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.
  18. If you can open the file, it is as simple as exporting to the excel or CSV format...
  19. Look for a custom function by the name "antiFilterValues" or roll your own with the While() function to iterate over the list. But in general: using fields for this kind of thing is perhaps not the way to go. You don't want to be adding a field every time you have a course with a different price point.
  20. In the interest of contributing to the community, maybe post how you ended up doing it so that the next person can learn from it?
  21. If you want to run a query on the whole courses table then your starting context doesn't matter, except that it may complicate things a bit in displaying the result. There are a couple of different ways to do this, one way is to run an executeSQL() query on the courses table that does a COUNT(*) and GROUP BY on the course total field. The result of this will be a return delimited chunk of text. You can show that in a global text field or go the extra mile and use a Virtual Table to display the result. If you are not familiar with SQL then this is a nice exercise. You can also display the results in a web viewer using a nice data visualization library. You can also just spawn a new window and loop through your course records (actually visiting each one or with the GetNthRecor() function) and keep a running tally per course total. Many options available to you. If you have tried one or two but got stuck, let us know what you have done already and we can see if we can get you unstuck.
  22. Definitely look at scripted solutions for updating totals. FM is more than a spreadsheet so it doesn't need to always work with nothing but calculations and summaries. While that is easy and get you going quickly, those things turn out to be serious performance impediments as your solution grows. Scripted workflows will bring tremendous power to your solution.
  23. Kinda depends on how you set up the relationship between Contacts and Companies. If you're working off the assumption that one contact can only belong to one company then you probably have a company id field on the contact record. As soon as you select the contact on your project, I'm going on the premise that you store the contact ID and thus have a valid relationship from project to contact. (Doesn't need to be so but it changes how you'd check for the contact's company id) Then at the point in your script where you decide on the project name you do an IF that checks if the company id field on contacts is empty: use the contact name, else (meaning the contact does have a company id populated) use the company name.
  24. Let's tackle this one first since it is not dependent on FileMaker Sever. What you need is to open your firewall / router for port 5003 and forward that port to the internal IP address of your FM host. Then your remote user would add a favorite host in their copy of FMP using the *external* IP address given to you by your ISP (you can find that easily with something like this: https://www.ipchicken.com/) A couple of thoughts: - unless your ISP provides you with a static IP address you may find yourself constantly telling that remote user what your new IP is. You can use a service like "Dyn DNS" or "No IP" to avoid that - your traffic will not be secure; since you are not using FileMaker Server you can't use a custom SSL certificate so your traffic will not be encrypted. This also means that your remote user is going to get no end of security warning messages every time they try to open the solution - you'll be hosting with your copy of FileMaker Pro; that's a feature that has been deprecated. If both you and your remote user do heavy duty work in the solution you'll both suffer since your copy has to serve you as well as that remote user. - for best results, give the machine that will be host a static internal IP address, otherwise you'll find yourself constantly updating the port forwarding on your firewall/router Not sure what that last "that" is. Without FMS there isn't a lot of web publishing you can do. So if this solution has some value to your business consider getting the entry-level license that includes FileMaker Server ($900/year, including the right to 3 FMSes and 5 users). If you can't/won't use FMS then I would suggest picking a good Form provider (like Typeform, Jotform...) and build your form there, then from inside FM, use their APIs to go and collect the data. Or if you are not up for API work, they can typically email you an excel sheet that you can import. Saves you from having to do any web publishing at all.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.