-
Content Count
5,906 -
Joined
-
Last visited
-
Days Won
191
Wim Decorte last won the day on November 3 2020
Wim Decorte had the most liked content!
Community Reputation
514 ExcellentAbout Wim Decorte
-
Rank
member
- Birthday 12/17/1968
Profile Information
-
Title
Sr. Technical Architect
-
Gender
Male
-
Location
Toronto
Contact Methods
-
Website URL
www.soliantconsulting.com
FileMaker Experience
-
Skill Level
Expert
-
FM Application
19
Platform Environment
-
OS Platform
X-Platform
-
OS Version
all
FileMaker Partner
-
Certification
7
8
9
10
11
12
13
14
15
16
17
18 -
Membership
FIleMaker Platinum Member
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
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
-
Wim Decorte started following FP5 conversion request, Can Fmp 14 database work with local host off-line like Fmp 5 used to?, Join Tables in Anchor-Buoy and 3 others
-
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?
-
Error 1920 - During the installation FileMaker Server 19
Wim Decorte replied to Selva's topic in FileMaker Cloud
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
-
FMS18 on Mac randomly crashing at around 11:55 PM
Wim Decorte replied to DataCruncher's topic in FileMaker Server 18
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. -
FMS18 on Mac randomly crashing at around 11:55 PM
Wim Decorte replied to DataCruncher's topic in FileMaker Server 18
We run hundreds of servers: when you turn it off it stays off. -
FMS18 on Mac randomly crashing at around 11:55 PM
Wim Decorte replied to DataCruncher's topic in FileMaker Server 18
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...