Skip to main content

The writer seems to be trying to write '00000000' for these features rather than leaving it as null

 

Is there a way to stop this behaviour? In a standard workbench I could set a default value but it feels like I shouldn't need to do that as postgres can handle null values in date fields and I don't know how I could change the values as it's a dynamic schema.

 

Errors in log:

Value of attribute 'createdate' could not be converted to type 'date'. Feature will be logged and skipped

 

Attribute(string: UTF-8)      : `CREATEDATE' has value `00000000'

 

---

Schema definition for field:

attribute{8}.fme_data_type fme_date

attribute{8}.name CREATEDATE

attribute{8}.native_data_type date

The next line is missing for features that do not have a value:

CREATEDATE 20031118

 

Are you sure that before the writer the value of CREATEDATE is null and not 00000000 ?

 

I have no issue writing nulls to a postgres date field


Thanks for you're comment, you are indeed correct the values are 00000000 before they go into the writer, the issue seems to be with the Shapefile reader as the values are null in the dataset when viewed in QGIS but are being padded out when read in FME:

 

NEXTTEST (string: UTF-8) 00000000


Thanks for you're comment, you are indeed correct the values are 00000000 before they go into the writer, the issue seems to be with the Shapefile reader as the values are null in the dataset when viewed in QGIS but are being padded out when read in FME:

 

NEXTTEST (string: UTF-8) 00000000

Shapefiles don't officially support null values which is why you don't see them as nulls. See

 

https://community.safe.com/s/question/0D54Q00008OcM97SAF/interpretation-empty-attribute-shape


Shapefiles don't officially support null values which is why you don't see them as nulls. See

 

https://community.safe.com/s/question/0D54Q00008OcM97SAF/interpretation-empty-attribute-shape

Thanks very much, that makes sense now.​


Reply