Hi,
I have set some fields from import and calculation.
The system setting number format on macOS is 1.234,56 - decimal comma
However, the number fields act strangely and do read 123,4 as 1234. So does the index. When I use a "replace field content" by myField+0, it becomes 1234. But when I edit the field manually and add e.g. a space, the 123,4 then is read as 123,4.
But when I use a replace by trim(myfield&" "), it remains 123,4, indexed as 1234.
Same for substitute("," ; ",")
So what's wrong here? Why doesn't FMP handle decimal numbers properly, how did it get confused and how do I unconfuse it?
I checked the "," - it actually is hex 2c.
It doesn't make any difference whether I tick or untick the menu command format -> use system formats
When I export as e.g. csv, the 123.4 is exported as 1234
The only working solution seems to be a scripted loop to add a space to that field - but there are several fields where this would be required and it feels like a terrible woekaround.
So is that an actual FMP bug?
Claris FileMaker Pro, Version 20.3.201 (12-19-2023).
...and I feel that this 12-19-2023 is a system bug, too and should either read as 2023-12-19, 12/19/2023 or 19.12.2023...
264,1 is when I select the field, how the actual content looks like. But obviously it's indexed as 2641 and displayed with the thousands separator as 2.641
I feel I'm just stuck in some stupid error here, too. I guessed it might have been because of fields operating on their own. So I now have created a sample test database and split everything to different fields. And it still fails to work...
So the task is: I have a FMP database and I want to import values, based on a matching ID.
The import table looks like
1
12,34x10x10,0
2
12x10x20,0mm
3
12,3mm*23,4mm*34,5mm
The first column is the ID. The second column are dimenstions XYZ (or BHT Breite, Höhe, Tiefe or WLD, width, length, depth).
The last row (or record) is 12,3 mm multiplied with 23,4 mm, multiplied with 34,5 mm. This web forum here does read the asterisk as a special formatting character. Let's try to fix that... I guess it looks ok with the ecape character backslash before - but if not, that's why I explain it here
All I want to to is to split that to the table
ID
X
Y
Z
1
12,34
10
10,0
2
12
10
20,0
3
12,3
23,4
34,5
I had preferred to update/import directly to the number field X. But if it does not work on itself, import could be done to a text field XYZ.
How numbers are read from text has nothing to do with how numbers are displayed in fields. Your system's settings determine how numbers are read from text.
It would help to know the calculation used to split the XYZ values into numbers.
