# Nuanced data-type behavior change in FM Pro calculation engine, v.19.6.1 **URL:** \ **Category:** Heads-Up!\ **Tags:** calculations, calculation-engine\ **Created:** [January 21, 2023, 4:20am UTC](https://the.fmsoup.org/t/nuanced-data-type-behavior-change-in-fm-pro-calculation-engine-v-19-6-1/3331 "2023-01-21T04:20:51Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![steve\_ssh](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/steve_ssh/32/160_2.png) [@steve\_ssh](https://the.fmsoup.org/u/steve_ssh)\ **Post date:** [January 21, 2023, 4:20am UTC](https://the.fmsoup.org/t/nuanced-data-type-behavior-change-in-fm-pro-calculation-engine-v-19-6-1/3331/1 "2023-01-21T04:20:52Z")
Hello, As best as I can tell, there is a small change in behavior in the FileMaker Pro calculation engine which occurred between v.19.5 and 19.6.1. Please note that I have not tested to see of this change occurs across all FM Pro platforms -- I have only investigated this on MacOS (12.6.1). **Background:** Behavior that I have always observed and expected is that many/most functions and operations in the FM Pro calculation engine return values which have an associated data type that corresponds to the result type of operations. **For Example:** There are some operations which one intuitively expects to return a value of type Text, such as the result of functions such as _Substitute_, _Left_, _Right_, or concatenation with the _&_ operator. There are other functions/operations which one intuitively expects to return a value of type _Number_, such as the result of the function _PatternCount_, or _Position_, or the result of using the arithmetic operator _+_. **Change Between 19.6.1 and previous versions:** In versions prior to 19.6.1, the _Trim_ function returns a value _which retains the data-type of the input value_. In contrast, in v19.6.1, the Trim function seems to always return a value which has a data-type of Text. It's a nuanced change, and for those of us who tend to explicitly cast values when there is any chance of uncertainty about the data-type, it is not likely to cause any issues. But, if you find yourself maintaining some code that makes assumptions about data-types, this is the sort of change that could result in code breaking with an update to v.19.6.1. I experienced this today with a solution that suddenly stopped working properly because a value which, prior to 19.6.1, had been treated as a Date, started being treated as Text when the FMP client version was updated to 19.6.1. The solution was to patch the calculation that was making an assumption about a variable's data type. It took me some time to track down the cause of the issue, hence I figured I'd post a heads-up to my friends here at the Soup, in case it saves anyone else some detective work. Some screenshots below attempt to illustrate. The screenshots show a comparison between v.18 and v.19.6.1. That said, I believe that the change actually happened between v.19.5.4 and 19.6.1. Also, to reiterate, I have only focused in on this matter on a MacOS machine (though, given the nature of the issue, I suspect that this will be change be present across all supported platforms. Hope this helps. **Behavior in v.19.6.1 of FileMaker Pro** ![v19.6](https://canada1.discourse-cdn.com/flex030/uploads/fmsoup/original/2X/5/5e22a13dc73368385c55c9a153a96b9a5088463a.png) **Behavior prior to v.19.6.1 of FileMaker Pro** ![PriorTo_v19.6](https://canada1.discourse-cdn.com/flex030/uploads/fmsoup/original/2X/4/43619d0e8dccf0859779592573cf379a592293db.png) ---
**Author:** ![MonkeybreadSoftware](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/monkeybreadsoftware/32/361_2.png) [@MonkeybreadSoftware](https://the.fmsoup.org/u/MonkeybreadSoftware)\ **Post date:** [January 21, 2023, 8:16am UTC](https://the.fmsoup.org/t/nuanced-data-type-behavior-change-in-fm-pro-calculation-engine-v-19-6-1/3331/2 "2023-01-21T08:16:49Z")
Interesting. I can confirm the change. 19.6 ![Screenshot 2023-01-21 at 09.11.20](https://canada1.discourse-cdn.com/flex030/uploads/fmsoup/original/2X/f/f7d697b7e6b17b26ea1af7190a82231b7c4d0eb2.jpeg) vs 19.5: ![Bildschirmfoto 2023-01-21 um 09.11.25](https://canada1.discourse-cdn.com/flex030/uploads/fmsoup/original/2X/5/566c5f377d483a475f913930be38f920d6822352.jpeg) vs 14.0 ![Bildschirmfoto 2023-01-21 um 09.12.42](https://canada1.discourse-cdn.com/flex030/uploads/fmsoup/original/2X/2/28f4bd874101424d12847fc75f0749f24771958d.jpeg) Seems like in recent versions Claris rewrote a few functions with unnoticed behaviour changes. ---
**Author:** ![mipiano](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/mipiano/32/1074_2.png) [@mipiano](https://the.fmsoup.org/u/mipiano)\ **Post date:** [January 21, 2023, 10:16am UTC](https://the.fmsoup.org/t/nuanced-data-type-behavior-change-in-fm-pro-calculation-engine-v-19-6-1/3331/3 "2023-01-21T10:16:40Z")
This is certainly an important discovery for many. Thank you @steve_ssh ---
**Author:** ![bdbd](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/bdbd/32/620_2.png) [@bdbd](https://the.fmsoup.org/u/bdbd)\ **Post date:** [January 21, 2023, 5:00pm UTC](https://the.fmsoup.org/t/nuanced-data-type-behavior-change-in-fm-pro-calculation-engine-v-19-6-1/3331/4 "2023-01-21T17:00:04Z")
Interesting… Claris should have documented the `Trim` function's behaviour change. That said, the help text for FileMaker 18 and 19 both say the `Trim` function returns text, so I would say this is Claris fixing the `Trim` function to behave as documented. (See FileMaker 18's help doc [here](https://help.claris.com/en/pro-help/content/trim.html) and FileMaker 19's doc [here](https://fmhelp.filemaker.com/help/18/fmp/en/#page/FMP_Help%2Ftrim.html%23ww1276331).)