Skip to main content
  • EN

I have an ID field that is correctly read by FME as varchar(22) when writing using the Feature Writer.

However, before that, I use the SchemaScanner, and it incorrectly detects the data type as fme_real64. As a result, the original value is eventually written in scientific notation, like 2.2072213393213062e+21, instead of preserving the original string format.

Is there a way to ensure that SchemaScanner correctly detects the field as varchar(22) to prevent this issue? Any suggestions would be appreciated!


 

 

I think adding a space to OBJ_ID as a suffix using an AttributeCreator before the SchemaScanner and remove this space afte the SchemaScanner using an AttributeTrimmer should work. It is hacky and a workaround, but I think it does what you need.

I think adding a space to OBJ_ID as a suffix using an AttributeCreator before the SchemaScanner and remove this space afte the SchemaScanner using an AttributeTrimmer should work. It is hacky and a workaround, but I think it does what you need.

A space did not work but adding # worked however fme_varchar(23) of course instead fme_varchar(22). Do you know why SchemaScanner messes up  like this? 

It tries to interpret the data type, but why this results in a scientific notation, I do not know. What data format are you writing to?

As to the char 22 vs char 23, you probably can solve this by inserting a dummy feature with a dummy 22 character string as id in the stream before the SchemaScanner and remove this feature after the SchemaScanner. This is probably more performance efficient as well.

Can you not set the type explicitly in an AttributeManager prior to the schemascanner?

 

 

​@ebygomm What do you mean explicitly? When I add AttributeManager, it immediately recognizes varchar(22) and SchemaScanner still think it is fme_real64 although I added AttribiteManager

​@jugoslaviaa Did you happen to sort this/ find a workaround? Getting the exact data type for my schema is very important for the validity of my data.

I also have this issue with my attribute data type going from fme_real64 to fme_int16.

​@jugoslaviaa Did you happen to sort this/ find a workaround? Getting the exact data type for my schema is very important for the validity of my data.

I also have this issue with my attribute data type going from fme_real64 to fme_int16.

Unfortunately, I could not find a plausible workaround

Community Stats

31,922
Posts
121,242
Replies
39,545
Members

Latest FME

Terms & ConditionsCookie settingsAccessibility statement
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.