Skip to main content

Hi

I have a workbench that goes like this :

Using FME Desktop 2014 (build 14339)

I'm using a FeatureReader to extract data (from SDE).

I'm using a FeatureReader to extract SCHEMA (attribute name and type) from the data extracted from SDE).

The schema is extracted because I need to change an attribute type before writing it to MapInfo (an SDE date attribute is formatted as fme_datetime and for MapInfo I need it to be fme_date).

I'm using python to change this and it works perfect.

Then I merge the extracted schema to every feature with the FeatureMerger and then output the data in Mapinfo.

The real problem is that I now need to change an SDE float attribut to a mapinfo decimal type (fme_decimal(10,5)).

FROM SDE : fme_data_type = fme_real64 and native_data_type = double

TO MAPINFO : the type is FLOAT

I try to change the fme_data_type and native_data_type to double (fme_decimal(10,5)).

In the workbench it's ok, but the mapinfo output is still FLOAT.

Any Idea?

Thanks!

Francis

Are you setting the fme_format_short_name ? This triggers FME to use the native data types instead of the fme data types see this article : section Using Format Specific Data Types. Set this to the format name for the Mapinfo writer you are using (MITAB or MAPINFO). I don't think you can mix and match using native data type vs fme data type, so if you choose to use native_data_type then you'll have to assign all your data types with that


Are you setting the fme_format_short_name ? This triggers FME to use the native data types instead of the fme data types see this article : section Using Format Specific Data Types. Set this to the format name for the Mapinfo writer you are using (MITAB or MAPINFO). I don't think you can mix and match using native data type vs fme data type, so if you choose to use native_data_type then you'll have to assign all your data types with that

 

Thanks for the info. I'v already try with the fme_format_short_name. That didn't work.

 

I can change the format to "date" or "char" but not to decimal...

 

 


Are you setting the fme_format_short_name ? This triggers FME to use the native data types instead of the fme data types see this article : section Using Format Specific Data Types. Set this to the format name for the Mapinfo writer you are using (MITAB or MAPINFO). I don't think you can mix and match using native data type vs fme data type, so if you choose to use native_data_type then you'll have to assign all your data types with that

I've attached a little test workspace that seems to work OK in 2014. dynamicwriternativedatatype2014.fmw If you inspect the resulting .tab file in a text editor, it looks like the attribute data types are set correctly.

 

!table

 

!version 300

 

!charset WindowsLatin1Definition Table

 

Type NATIVE Charset "WindowsLatin1"

 

Fields 2

 

attr1 Char (10) ;

 

attr2 Decimal (10, 2) ;

 

This is a little easier to configure in newer versions of FME. If this doesn't work for you then perhaps send an example workspace and data to support@safe.com
I've attached a little test workspace that seems to work OK in 2014. dynamicwriternativedatatype2014.fmw If you inspect the resulting .tab file in a text editor, it looks like the attribute data types are set correctly.

 

!table

 

!version 300

 

!charset WindowsLatin1Definition Table

 

Type NATIVE Charset "WindowsLatin1"

 

Fields 2

 

attr1 Char (10) ;

 

attr2 Decimal (10, 2) ;

 

This is a little easier to configure in newer versions of FME. If this doesn't work for you then perhaps send an example workspace and data to support@safe.com
Thanks Mark for the try...

 

As I said, I can format the output attribut to char or date but not to decimal.

 

The datasource is SDE (in a SQL database).

 

Maybe It works when the SchemaSource is Mapinfo and the output is Mapinfo too.

 

I can change the attribut name too...

 

The source attribut in FME is 64 bit Real. In SDE the format attribut is Double.

 

I put a static schema for that particular table to avoid the problem.

 

Hope in a newer version it's ok!

 

Thanks!

 

Francis

 


Reply