Skip to main content
Solved

Inconsistencies when reading File Geodatabase with a FeatureReader

  • December 9, 2024
  • 6 replies
  • 65 views

tbarker1986
Contributor
Forum|alt.badge.img+4

Hello,

I am experiencing some odd behaviour with the FeatureReader when trying to read in a schema from a Feature Class in a FGDB. I am using the “path_windows” attribute that contains the location of the gdb. When run like this, I often get a rejected message (see Caption 2). When I add in the hard coded full path into the Dataset field of the FeatureReader, the data gets read correctly. What is strange is that this has been working fine in the previous weeks when I had developed it. It only appears to be an issue since today. It also seems to read successfully when I run the workbench with caching to the Aggregator before the Feature Reader, then running again from the aggregator (no settings have been changed). I have tried using the path_unix field instead, but get the same error. I have also tried other datasets, but get the same issue.

Has anyone experienced similar behaviour when using the FeatureReader with a GDB?… and any ideas to help with the stability of the run? The workbench is part of a series of child workbenches that will get run on FME Flow each night so need to ensure consistency. Any help would be greatly appreciated.

The GDB version is 10.0

FME version: 2023.2.1.0 (Build no. 23774)

Caption 1: Feature Reader and FME attributes
Caption 2: Error message in Log
Caption 3: Example data that is being read

Cheers,

Tom

Best answer by liamfez

Looking at your log again it mentions licensing; perhaps try changing the reader format to FILEGDB (open API) instead of the licensed GEODATABASE_FILE format you are currently using.

View original
Did this help you find an answer to your question?

6 replies

liamfez
Influencer
Forum|alt.badge.img+34
  • Influencer
  • December 9, 2024

Not really a solution, but an idea to test:

I feel like I have had this happen before, though it was awhile ago. One thing you could try, since you said hardcoding the path worked correctly, would be to try hardcoding the start of the path instead of the entire path coming from one attribute value. Something like D:\Folder\@Value(path_windows)


tbarker1986
Contributor
Forum|alt.badge.img+4
  • Author
  • Contributor
  • December 10, 2024

Thanks for the suggestion ​@liamfez - just updated the workflow, however the same error is still cropping up. Initially tried it when cached up to the Aggregator and it worked, then tried rerunning the full flow and it failed.

In addition, the reader_error attribute created contained the following message (this was the same for full path from attribute and part path from attribute).

“Failed to obtain any schemas from reader 'GEODATABASE_FILE' from 1 datasets. This may be due to invalid datasets or format accessibility issues due to licensing, dependencies, or module loading. See logfile for more information”


tbarker1986
Contributor
Forum|alt.badge.img+4
  • Author
  • Contributor
  • December 10, 2024

I’m running through some further testing… changing settings etc to see if there is anything that can force consistency in the reads.

So far, the most promising option is to Enable Cache in the FeatureReader with a timeout of 1hr. Currently i’ve run through 2 full runs successfully, but will have to see if the error crops up again and keep this chat updated.

Really interested to get thoughts on if this would likely be a long term solution or if there may be a better way?


liamfez
Influencer
Forum|alt.badge.img+34
  • Influencer
  • Best Answer
  • December 10, 2024

Looking at your log again it mentions licensing; perhaps try changing the reader format to FILEGDB (open API) instead of the licensed GEODATABASE_FILE format you are currently using.


tbarker1986
Contributor
Forum|alt.badge.img+4
  • Author
  • Contributor
  • December 11, 2024

Thanks ​@liamfez. I was still getting rejections when running with the cache so this new suggestion is appreciated.

I’ve updated the readers to the FILEGDB (open API) one and so far seems to be working well. Only difference is that I need to exclude any non geometry items, which you can do in the licensed GEODATABASE_FILE format, but not the FILEGDB (open API). I got around this by exposing the fme_geometry{0} attribute and removing any “fme_no_geom” datasets. 

I’m feeling more confident with this, but will keep this thread updated in case that changes. Thanks for your help with this!


tbarker1986
Contributor
Forum|alt.badge.img+4
  • Author
  • Contributor
  • December 13, 2024

Hi All, just updating this with some further findings. I’m still getting some inconsistencies reading. I’ve added both readers in (Open API & Licensed GDB) so if it fails on 1 it will try the other. This seems to be working better, but still getting some issues. Doing a little digging in the logs and there is mention that

“FileGDB Reader: Feature class 'Chalk_Rivers_England' has shape type 'esriGeometryLine' which is unknown to FME”

Any ideas on reasons for this or ways to change this shape type for the Feature Class before reading into FME?

 

 


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings