I'm writing data to a hosted ArcGIS Online feature Service, one field is of type string but I sometimes writes an integer to it. When I do that the number is converted to decimal. So 25 becomes 25.0.
Has anyone solved this (without adding a space at the end)?
Hi @nissedahlsten,
I threw in some test data with some integers only, some mixed text and integers, some interspersed with spaces, some with no spaces, all with type string, and writing it out to AGOL, but I can't seem to reproduce the behavior that you're experiencing.
Would you be able to share a test workspace and some sample data? I'd also be curious to see the User Attributes in the AGOL writer, if you're able to share a screenshot?
Hi @jovitaatsafe,
I managed to get this working by adding a trimmer to my attribute just before the feature was output.
The trick is to convert the datatype to string at the end, with AttributeTrimmer I got UTF8 instead of Real64. You can verify this by redirect writer to Inspector (and of course perform an actual output! 
).
What I saw was that even thou my featuretype def for my attribute was string, fme passed the actual attribute value out as real64, which then ended up in AGOL with a decimal. So 23 became 23.0.
May there is some other neat way to force FME to honor the datatype of an attirbute value to what the definition is set to (or maybe you see this as a bug).
If not, I think it should be put on the "to-do" list. Something like a parameter on the featuretype output definition that let the user explicitly tell FME to perform a data type conversion according to the attribute definitions.
If you need, I've got 2 sample workspaces and data that goes to an open featuretypeservice that you can try out. Let me know and I'll send it over.
/Nisse
Hi @jovitaatsafe,
I managed to get this working by adding a trimmer to my attribute just before the feature was output.
The trick is to convert the datatype to string at the end, with AttributeTrimmer I got UTF8 instead of Real64. You can verify this by redirect writer to Inspector (and of course perform an actual output! ).
What I saw was that even thou my featuretype def for my attribute was string, fme passed the actual attribute value out as real64, which then ended up in AGOL with a decimal. So 23 became 23.0.
May there is some other neat way to force FME to honor the datatype of an attirbute value to what the definition is set to (or maybe you see this as a bug).
If not, I think it should be put on the "to-do" list. Something like a parameter on the featuretype output definition that let the user explicitly tell FME to perform a data type conversion according to the attribute definitions.
If you need, I've got 2 sample workspaces and data that goes to an open featuretypeservice that you can try out. Let me know and I'll send it over.
/Nisse
Hi @nissedahlsten,
Glad you've got a workaround figured out! Yes please to the sample workspaces and data! I would love to take a look at where it's being interpreted as real64 instead of a string and see whether we can do something about that.
Hi @nissedahlsten,
Glad you've got a workaround figured out! Yes please to the sample workspaces and data! I would love to take a look at where it's being interpreted as real64 instead of a string and see whether we can do something about that.
@jovitaatsafe I found this thread because I'm seeing the same behavior, do you still need samples? In my case I'm reading Excel files with a FeatureReader that refuses to read a column as not-number (even when I manually change the attribute type to string, it resets?), and from there, unless I use the AttributeTrimmer trick, that attribute is real64 and writes with a decimal despite the destination attribute being a string. So this may be primarily a FeatureReader-of-Excel problem in my case...
Hi @nissedahlsten,
Glad you've got a workaround figured out! Yes please to the sample workspaces and data! I would love to take a look at where it's being interpreted as real64 instead of a string and see whether we can do something about that.
Hi @mtaftferguson sorry to hear that you are running into this issue, are you writing the data out to AGOL? Or is this related to reading the data in? What version of FME are you using?
Hi @nissedahlsten,
Glad you've got a workaround figured out! Yes please to the sample workspaces and data! I would love to take a look at where it's being interpreted as real64 instead of a string and see whether we can do something about that.
Hi @daraghatsafe . Yes, I'm writing to AGOL. The cause seems to be the same as above on the writer side (the attribute is coming to the writer as real64 type; if I change that before it hits the writer then all is well on the writer side), but the fact that the attribute is being interpreted that way seems to be an issue with the reader (since I cannot "force" the reader to read it as a UTF-8 string, even though it looks in the UI like I should be able to). I'm using FME 2021.1