Skip to main content
  • EN

Hello,

 

I just moved to fme 2019 and in this example I'm using workbench  FME(R) 2019.0.1.0 (20190506 - Build 19253 - WIN64)

 

 

I have very simple workspace: creator -> featurereader (postgis) -> gml writer

 

 

0684Q00000ArAy0QAF.png

 

When I run it I don't even get to the breakpoint. On reader there is log:

 

 

 

2019-07-18 21:46:06|   7.6|  7.1|FATAL |POSTGIS reader: An error occurred. FME will attempt to provide more information on the error, but this may cause the translation to be terminated

2019-07-18 21:46:06|   7.6|  0.0|INFORM|Successfully closed POSTGIS database reader

2019-07-18 21:46:06|   7.7|  0.1|INFORM|Successfully closed POSTGIS database reader

2019-07-18 21:46:06|   7.7|  0.0|FATAL |POSTGIS reader: stk::ex::bad_expected_access

 

 

 

I discovered that problem is with one row. In column of type:
timestamp with time zone  

value is:

-infinity

In version fme 2016 I don't have that problem. I executed that workspace with fme 2016 and 2019 and here I can see the difference in fme postgis reader version:

 

 

0684Q00000ArB0GQAV.png

 

I did the same using sql executor, not feature reader and result was the same.

 

 

0684Q00000ArAzJQAV.png

 

 

When I skipped that row using where statement, job was completed without any errors. 

 

 

 

Do you know how can I protect against that error?

My suggestion is to get rid of the infinity value. As a workaround you can copy the old reader from the 2016 workspace into the 2019 workspace.

Hi @witos,

Try adding a NullAttributeMapper transformer to map the infinity values not null.

Hope this helps,

Itay

Hi @witos,

Try adding a NullAttributeMapper transformer to map the infinity values not null.

Hope this helps,

Itay

Should it be after reade? If yes then it will not work because I don't even hit a breakpoint. It fails on reader.

Should it be after reade? If yes then it will not work because I don't even hit a breakpoint. It fails on reader.

Yes I see that now...then some value changing in de database (via SQL) before reading?

Hi @witos,

 

 

Thanks for your question! It looks like the representation of infinity has changed since 2016 which is why you are seeing it work in 2016 but not in 2019. In the PostGIS reader documentation for FME 2019, under User Attributes, float4 and float8 have a note about not supporting special floating type values such as Infinity.

I think that @stalknecht's suggestions will be your best solution for now. I'll see if I can find out anything more on it, and I'll aim to get back to you early next week on it as the developer I need to talk to is currently away.

Hi @witos,

We were able to reproduce the issue here and I've filed an issue in our tracking system (FMEENGINE-61049) as we shouldn't terminate the whole read process due to the invalid -infinity value. I'll let you know as soon as it has been addressed. Thanks for bringing this up!

Hi @witos,

I'm pleased to inform you that a recent update has implemented a fix for the issue reported as (FMEENGINE-61049), so that the translation no longer fails, and will now warn you that infinity is not supported and will default to null. You can find this update in FME 2019.2 (build 19749 or newer) from the beta downloads here. Thanks for letting us know about the issue!

Reply


Community Stats

30,108
Posts
114,295
Replies
37,745
Members
Terms & ConditionsCookie settings
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.