We have an issue where a user has large text amounts in regular FileMaker text fields -- well within the stated text field size limits.
FileMaker, at least with its default settings, doesn't handle these text fields well as the user when clicking into a large text field gets "beachballs" and non-responsiveness. The only solution is then to force-quit and restart. That restart doesn't solve the problem, but then the user doesn't try to click in to a large text field and try to scroll or edit anything.
So, the question is, how can we, like in other development products, configure FileMaker to use more memory and hopefully make it usable for large text fields?
Sure, it's a FileMaker app accessing FMS on a 32-GB AWS Windows 2019 server. No VPN. But the problem will also happen with a local FMP not connected to anything if you have lots of text in a text field.
• What version of FMS and FMP?
• For FMP, what OS? (macOS or WIndows)
• you mentioned "beachballs" which sounds like macOS. In that case, please do this:
Open the app Activity Monitor
find FileMaker Pro in the list of processes and click it
from the popup menu, choose Sample Process
Within 5 seconds, reproduce the issue in FileMaker
You will get a Sample which shows what functions are taking the most time.
we are working with xml files and for some reason, we loaded the xml-text into a FileMaker field (for faster processing).
Over the years, there were no problems at all - but beginning with the 3. quarter of 2022, we received xml with blob's.. FileMaker under Windows was making troubles, hang, we had to restart the FMS. One supplier sent over 2000 xml files with up to 25MB size. Did no longer work with FMS.. I deleted all of the text-field content and stopped storing the xml content.
Without storing the xml, it works perfect again. I got a script that extracts the blob and shows it (as pdf). Under Windows, I was not able to process every file - on macOS, there was no prblem (although it became slooow)
I got a gut feeling that something on the whole'connection' under the Windows environment lacks something here - but can't get any help
Though I don't have any insight with respect to memory settings that could help with this, I can second the observation that, at least on MacOS, the act of clicking into a field with a large amount of text will cause a delay (and possibly beach ball) that increases as the amount of text increases.
My sense is that the delay is specifically related to the UI rendering related to clicking into a field, as I have not noticed any similar symptom of delay when I reference the field in a calc in the Data Viewer.
FWIW: I've noticed this with past MacOS versions of FMP, as well, e.g. perhaps as far back as v.14
Can you modify the UI to reduce the user interaction with the text?
Controlling the user interactions through the UI to avoid the need to open and load large text could provide the usability that you need. For example, a web viewer could act as an XML reader and may be more performant.
I had the same experience on Mac Monterey, FMP 2023. It took about two seconds for the field to open for editing.
However, a web viewer, on the same layout using the formula "data:text/xml," & fieldName gave me instant access and had the benefit of formatting the xml with colours and providing reveal/collapse arrows to control the content outline.
What @Malcolm said, at least for rendering.
Also, where is the need to store these xml files as text fields. Text fields (just as all fields by the way) are stored in UTF-16 in FileMaker, which is very heavy. Here are a couple of advices when dealing with large texts:
store them in a dedicated child table. Every time FileMaker touches a record it has to download it entirely. Say your xml file is stored in a field of your Contacts table, you will download this massive amount of data everytime a Contact record is displayed or used in a calculation. So it's better to store it in a Contact_largeField table with just ContactID, LargeField.
for XML and things like that, is there a benefit in storing them as texts? why not containers with external storage? You can always read from containers using Base64Decode ( Base64Encode ( container )). You can't perform find in containers or export them in CSVs for instance, but that is not really things you want to do with an XML file (don't perform finds in them or they will produce a huge index!)
