We seem to have touched on a number of standard FileMaker features that no longer seem to perform as they used to and wondered whether we could create a list of those old favourites that we’re now trying to avoid, either due to reduced performance within the later releases or for designing for use over a LAN.
I’ve already created a post dedicated to the demise of Go to Related Records (GTRR) and @Torsten has recently potentially added ‘Set field by name’ to this list although this could be a bug, but at the moment we don’t know.
Here we’ve been trying to keep to lean development as much possible for years, trying to avoid any cross-table calculations and where possible set calculated values using scripts.
As far as I can see, there has been a move within all software development to cache what can be seen and populate the rest as and when needed. We’ve seen this in Word, for long documents, Outlook mailboxes and portals in FileMaker, which seems to result in a lot more ‘spinning wheels’ than previously and not necessarily only when dealing with large data sets. The concept that a complete Word file wouldn’t be uploaded in its entirety a few years ago would have been completely alien to us.
My heart sinks every time I land on a layout that has summary fields displayed, where again I’m waiting for these to process before I can commence work. Quite a few years ago I did include layouts with sub-summary parts in an invoicing system that relied on sort order and population of fields in the first and last records (equivalent of leading/trailing) within the sub-summary break via scripts to omit the need for summary fields. It did work, but I never followed this up to compare performance against standard summary fields, particularly with large data sets. The problem with any script driven system is updating summary data in parent records that calculation/summary fields do automatically.
So as a starter for ten ‘available but not recommended’ list:
Go to Related Record
Long chains of table occurrences
Unstored cross-table calculations fields
Sub-summary fields
Calculation fields using the ‘Sum’ or ‘GetSummary’ function
Tables containing large number of fields
Possibly ‘Set field by Name’ (this remains open at the moment)
ExecuteSQL whilst a record is in an open state
Finds on calculation fields
Possibly cross-table finds
Sorts on large data sets, particularly references to fields in linked TOs
Replace field contents (for users, we couldn’t do without this as developers)
A list with little or no explanation, and no link to reference material, may not have the impact you would like. Others, not as familiar with the deep knowledge of the issue listed, may assume that FileMaker is just not capable…and we know that’s not true.
Just glancing over the list, I use many of those things, with no issues. It’s obviously about using the tools for their strength and not just throwing a blanket over it and saying, ‘you should never use these’.
I’m hoping once we get a consolidated list that we can then put the flesh on the bones. It isn’t an attempt to knock FileMaker, but to ensure people can understand why something that has been designed to work, doesn’t necessarily work efficiently.
Many of us have been knocked backwards by using tried and tested techniques with the latest versions, many documented here and on the official forum. Hopefully, we can not only identify these, but offer alternatives as well.
This list can be considered as a starter, as work in progress. Like any technology, FM has strength, capability and limitations. For aircraft, strength and capability lies within what is called the flight envelope, limits define the borders of that envelope. This gives a pilot information about how he can safely operate the aircraft and what he shall not do in order to avoid failure and accident. For FM, we have official documentation that covers most of the capability and strength topics. Official information about limits is scarce. Like a pilot, a developer needs to know these limits and we need work on our own collection of information about limitations. I therefore welcome @AndyHibbs initiative.
@AndyHibbs, the issue with the spinballing file https://the.fmsoup.org/t/fmpa-memory-leak-when-looping-over-large-data-set-with-calculated-field-on-layout/378/33 is a good example why it is valuable to collecting this kind of information. It appears that the ‘Set Field By Name’ step is not the cause but an undocumented type conversion requirement (ref. link above).
I haven’t found any product documentation about the detrimental effect of omitting the type conversion in exactly this context.
So, the venerable ‘Set Field By Name’ can go off the list and ‘Type conversion’ should be on it.
It seems the initiator for that thread is @AndyHibbs
Just like the thread we are in today. It is an initiative I like, but I feel there are many challenges on the road. I’m curious to see how this unfolds.
Maybe put a ‘missing type conversion’ alert out? Oops, I think that’s what you’ve already done.
I’ve just replied to your post on this, but it is a fantastic example of doing nothing wrong but getting it totally wrong. I still have a nagging ‘its a bug’ voice in my head.
My recent journey took me to ‘field type’ and ‘script & custom function debugging’. FMP’s debugger does not issue warnings or error messages when a value is copied into a field, even when that value’s format does not conform to the field definition and actually will brake the file.
The recommended strategy is typecasting, each time a value is copied to a field.
Instead of
Set Field [table:field ; $value ]
do
Set Field [table:field ; GetAsNumber ( $value ) ]
when field is of type ‘number’.
Improved support by FM’s debugger would be most helpful. Type validation in debug runs is state of the art in almost all modern systems. If a type violation has the ability of breaking the file, a warning issued by the debugger is mandatory.
I would prefer a non critical error be raised, so we could keep inserting text in number fields if we want, but if we want to avoid it, error trapping would let us implement what is needed from there.
The interesting part is that even with “Numeric-only” validation on, spaces are allowed at the end of a number. It is those spaces that are causing an issue, presumably with the index. I’m sending in a revised sample file that was asked for by Claris. They are interested in looking at the problem.
@jormond do you have a red phone under the table or how are you able to access Claris/FMdev to look into it. Mere mortals like myself or as I understood @Torsten get bounced back (kind of).
.