I haven't seen this discussed anywhere, but it seems worthy of note.

Number fields in version 7 do not ignore text characters until a numeric calculation is performed on the field or it is referenced inside GetAsNumber. Length(numberfield) returns 4 for "0001" and "FRED", whereas previous versions would return 1 and zero. Left( numberfield; 1 ) returns "A" for "A12", versus "1" in previous versions. Length(GetAsNumber(numberfield)) and Left( GetAsNumber(numberfield); 1 ) produce results consistent with previous versions.

Once the number is added, multiplied, etc., then the characters are ignored, although if only text is in the field, it treats the number as zero instead of null. numberfield + 1 returns "1" for "ABE" instead of null.

This could cause problems for serial numbers or other fields defined as numbers that contain text which would previously have been ignored, depending on the type of calculations for which they are used. It is a nice feature where leading zeroes are concerned and surely can be utilized in other ways.

My only question now is how are number fields different from text fields, aside from how they sort?

>My only question now is how are number fields different from text fields, aside from how they sort?

Number fields do not accept return characters ....

There is an inconsistency between GetAsNumber() and properties of number fields. This is a bug worth to be reported ...

Just make some more tests, though ... "Y", "T" were interpreted in FMP 6 as 1, (yes, true), and "N", "F" as Zero. This has been changed in FMP 7. GetASNumber("true") returns nothing.

Yes, I was aware that 'true' was no longer true. I just never saw anything regarding the new way number fields behave. Would you consider this a bug then?

True that number fields do not accept return characters, as long as they are manually entered. You can set a number field with return characters via script and use it for a multi-key relationship. Of course, there is a much smaller limit on indexing than there is with text fields.