• Home
  • Forums
  • FME Flow
  • General
  • Two FeatureWriters writing to the same output File Geodatabase, second writer fails in fmedatadownload service
Question

Two FeatureWriters writing to the same output File Geodatabase, second writer fails in fmedatadownload service

  • 11 July 2022
  • 1 reply
  • 16 views
aegman
Badge +1

Hi,

I'm having an issue using FeatureWriters on FME Server (22350).

 

What I'm trying to do is create a File Geodatabase with a feature writer, then later in the same workspace remove selected features from feature classes in the File Geodatabase that has been created.

This works in desktop and as a fmejobsubmitter serivce, but when using the fmedatadownload service the second feature writer throws an error that the featureclass/database does not exist.

 

I assume this is related to how FME Server adjusts the paths for data being created for the data download ZIP file? Both FeatureWriters are linked to the same parameter for the output FGDB.

I have tested using a FeatureReader with the same parameter for the FGDB, and it successfully reads from the created FGDB.

 

Is there some parameter or configuration I can use to ensure that both FeatureWriters are using the same path for the FGDB? (I've tried the FME_SHAREDRESOURCE_TEMP but that didn't help).

 

I've attached a simplified example, it uses the Natural Earth Countries Shapefile, writing to a FGDB and then deletes the first record read from the Shapefile.

1 reply

aegman
Badge +1

As is the way with these things, had some inspiration overnight, and have been able to rework the workspace so that all features are written with a single FeatureWriter, using fme_db_operation attribute. Sample workspace attached.

 

I think my original question is still valid though as there may be situations where it's not possible to prepare the deletes before writing (e.g. attribute rules in FGDB). Its also puzzling that the FeatureReader can read from the FGDB, but the second FeatureWriter complains it doesn't exist.

 

To answer the question of why I'm even writing features that I'm immediately deleting, in this case its to force the creation of an empty feature class when using a dynamic schema. Users want all their selected feature classes present in the exported data even though there may not be any features in their selected AOI.

Reply


Community Stats

28,670
Posts
109,364
Replies
36,531
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.