When "=" doesn't mean equal

[mcstar]

I have a system that needs to compare the before and after values of a bunch of fields. There is a calc field, cFieldValues, that strings together the important fields and separates each value by a delimiter character and carriage return. When the user clicks the button to enter the edit mode screen, the button script puts cFieldValues into a global gStartValues. When the user saves the record, the button script has an IF statement that compares the current cFieldValues to the global with a simple "=" operator. If there are changes to any field values, other stuff needs to happen.

This seemed like a sure thing until I began to see records with more than 255 characters in the cFieldValues calc result. For the 256th character and above, the "=" operator does not detect inequalities if characters are changed but the total number of characters stays the same. For example, if the string does not change for 255 characters but at the 256th character "one" gets changed to "two", then the comparison sees the before and after strings as the same. If "one" gets changed to "three", then the comparison sees the strings as different.

I couldn't find any documentation regarding the limit to the size of strings that the "=" operator could work with.

To fix the problem I am using the PatternCount function to compare the before and after values:

If (PatternCount (cFieldValues, gStartValues) + PatternCount (gStartValues, cFieldValues) <> 2, "Different", "Same")

The PatternCount function seems more robust. If anyone has any comments, I'd love to hear.

Bye! -- Mark

[Tripod]

I wonder if this might be a lot easier in FM7. First of all, you can commit changes or not so there might be some sort of status flag indicating if the record has changed that you could access (would be nice), but also, the max characters in a field is much larger, so perhaps the IF stmt would read farther into the field (record). Remains to be seen if the functions are any different though, when comparing fields, etc...

I am still only playing with FM7, have not actually done a project with it YET...

[Vaughan]

I believe the string comparisons have the same limits as indexing: first 20 characters of each word, 60 words (or something like that).

[The Shadow]

In FM7, the indexing limits are 100/100, not 20/60 anymore. The 60 was for the length of a "value", which is everything up to a newline. The values are used for joins, unique / existing validation, etc.

I tried an example comparision in FM7, it recognized the difference out past the 500th character. I didn't bother checking out any further, but I would doubt there is a limit.

[cjaeger]

Just dont try to use the "=" operator on a number field when it contains text.

"=" does mean EQUAL all the time.

Number fields only can hold 256 characters, or at least, only 256 characters are calculated/considered for equation.

Tested with: FMP6dev, FMP7dev.

Just try fieldA=fieldB with a text field with 60000 characters. It just calculates rigth, as does the Exact()= function. Now try the same with fieldA and FieldB set to Number.

btw: Just have a look at the field defs of cFieldValues calc result