FileMaker 20.3 introduced a change that affects those of us who are using the undocumented ReleaseDebugOn feature flags.
Before we outline the change, a word of caution: any of these feature flags are subject to change without notice; it’s why they are undocumented. Mostly, they are there for short-term testing before a feature makes it into the mainstream of documented functionality; others are there for troubleshooting and debugging.
We have blogged about how to use these effectively for those efforts, specifically to overcome issues with FileMaker’s temp files and to get detailed logging of all operations that happen at a client’s machine or at the server. You can find the blog post from version 19.1 here, and from 19.5 here. While we are entirely comfortable using this for troubleshooting and tweaking performance. When you use this to enable nested PSoS, for instance, then you need to be aware that you are enabling an unsupported feature, so don’t do this lightly. Also, know that this feature flag may disappear without notice – consider these experimental features.
When you run a version of FileMaker Pro or Server that is at version 20.2 or below, then the ReleaseDebugOn.txt file will work as explained.
When you have FileMaker Pro or Server version 20.3 or later, then it won’t; there is a new format for the features flag file. That file is now a JSON file named ClarisConfig.json, and inside that file, you add the flags you need and set them to true or false:
{
"some_feature_flag": true,
"some_other_feature_flag": false
}You can leave the file in the same location as where you had the ReleaseDebugOn.txt file: where the FileMaker Pro or Server executable is. You can also now put it in the client’s Documents or Server’s document folder.
Navigating Changes in FileMaker
FileMaker is evolving at a quick pace, and there are many new tools, features, and resources to navigate. If you’d like some technical support in implementing them into your FileMaker application or would like help customizing your solution, contact our team to speak with a consultant.
Thanks Wim. Previously our Windows users used the flag, extraflags:no_portal_drs to deal with disappearing portal data. We’ve tried {“extraflags:no_portal_drs”: true} and {“no_portal_drs”: true} in the ClarisConfig file but neither seems to solve the issue.
{“extraflags”: “no_portal_drs”}
That should work.
Thank you very much!
Weirdly, it seems that even FM Pro 20.2.1 is already ignoring ReleaseDebugOn.txt and only reflects ClarisConfig.json
I’ve been trying to figure out where to put the file.
The Salient website says: Program Files/Filemaker/FileMaker Server/Database Server/
(source: https://www.soliantconsulting.com/blog/filemaker-sharing-locks-feature-flags/ )
But I don’t have a FileMaker Server or Database Server folder in Filemaker 20
Honza, are you saying that the ReleaseDebugOn.txt file doesn’t work? I’m not sure what the ClarisConfig.json file is, does it provide a workaround to portals not loading on Windows?
Recent versions of FMP and FMS don’t use the ReleaseDebugOn feature flag file anymore, they use a new format: ClarisConfig.json. Read up on it here: https://www.soliantconsulting.com/blog/filemaker-releasedebugon-feature-flags/
It sounds like you are looking to use this on FMP, in which case you put the file where your FMP executable is. And yes: the same flag that could be used to help solve portal issues can still be used in this new format. And also make sure to open a support ticket with Claris so that your input can help track down the core issue.
Thanks Wim… can you remind me where to enter Claris Support Tickets?
On community.claris.com, under Discussions there is a list of links on the right-hand side. One of them is “report a product issue”.
https://community.claris.com/en/s/topic/0TO0H000008OQOGWA4/report-a-product-issue
Or call support directly which will give you a ticket number and email follow-up.
Dear Wim, I tried using the flag:
{
“NormalTempFile” : true
}
but upon exiting Filemaker the cache is not deleted.
I also tried with false, but without success.
Same with both MacOS and Windows.
I placed the ClarisConfig.json file in the Applications folder (Mac) and in the C\Program Files\FileMaker\FileMaker Pro 20 folder (Windows).
What am I doing wrong?
A thousand thanks
Make sure to also include the AlwaysPrint and ForceOutput flags, then check the debug log that gets created in that same folder to see if reports that the flags were enabled.
I understood why.
Without the flag, the cache is created in
Macintosh HD/Users/_user_/Library/Caches/FileMaker/DBcache
while with the flag in which it is created
Macintosh HD/private/var/folders/…
and when FileMaker pro closes it is correctly deleted.
I was looking in the wrong place
Thanks Wim
Wim – Have you tested ClarisConfig.json on Linux? My FMS 2024 seems to be ignoring it so I can no longer use SupportNestedPSOS.
Yes, the ClarisConfig.json works in FMS 21.0 on Linux. But I haven’t tested server-side PSoS since it’s not officially supported. These feature flags can come and go and shouldn’t be relied on, especially those that unlock features for testing.
Is there a way to confirm that the ClarisConfig.json was processed when the server is started? I do not see any mention of it in the logs.
Set the AlwaysPrint and ForceOutput flags. The activity is not logged in any of the usual logs but if the ClarisConfig.json file is recognized and used, there will be various debug logs in the same folder. Look for instance for the fmsDebug.log.
Hi Wim, and thank you for your post.
I’m using the {“extraflags”: “no_portal_drs”} on the clarisconfig file tring to solve the issue about the disappearing portal data. It seemed to work but now is acting funny again.
I’m using it on Win1. Do you know anything about this problem?
Hi Ivan,
Yes we’ve seen the same portal issue crop up now and then. I would suggest you post to community.claris.com with some details about how “funny” manifests itself and see if others have had the same problem and potential fixes.