Question

FeatureWriter won't create new GDB on network drive

  • 6 August 2019
  • 7 replies
  • 7 views
W
Badge +1

About a week ago, FeatureWriter (Version 0, there doesn't appear to be a newer version available) in an existing workbench, no longer creates new Esri File Geodatabases on network drives/shares. The bench had not been changed between the previous run when it worked and the subsequent run when it did not.

It will NOT create new GDBs on any network location, on any server, using either mapped drive letter path or full UNC path.

It WILL truncate, drop/create tables in an existing GDB in the desired network location.

It WILL create new ESRI SHP files or AutoCAD DWG files in the desired network location.

It WILL create new GDB on a local (C:) drive.

I have verified that I have create, modify, read, delete permissions to all of the tested network locations.

Updated to a clean install of the newest version of FME Workbench (19.1), no change in behavior.

Tried creating a brand new, empty workbench, inserting a brand new FeatureWriter to rule out some altered setting or parameter being the culprit, no change in behavior. (Repeated this in both 2018.1 and 2019.1).

Anyone got any other ideas? I'm fresh out.

UPDATE 2019-08-07:

After a lengthy chat with Safe tech support, I found a workaround. When adding the Writer or FeatureWriter, configure it to use an existing GDB as a template. Create your template as an empty GDB, and the FeatureWriter copies it first (the copy operation works), and then write all of the new feature classes into the empty GDB. It's a bit of a kludge, but it works for now. I've opened a support case as well.

 

7 replies

nielsgerrits
Rank
Userlevel 6
Badge +32

Any warnings or errors in the log? Any spaces in the path? What type writer do you use? (File Geodatabase or the Open API) Does it run local or server? Any software updates? Special characters in dynamic generated gdb name?

W
Badge +1

Thanks for the reply nielsgerrits .

The errors message in the log is "Unable to connect to geodatabase...", just as if it were trying to open an existing GDB that had a schema lock.

I have tried saving to multiple network locations, with and without spaces in the path, all with the same results.

I'm using a FeatureWriter configured for Esri Geodatabase (File Geodb), but I've also tried this with the standard Writer for Esri Geodatabase (File Geodb), again with the same results.

The application is running local on a VM.

Neither the application nor the VM nor any software on the VM had any updates between the last time the bench ran successfully and when it began failing.

I originally had the FeatureWriter configured to append the current date to the GDB name, but one of the first things I did in my tests was to eliminate that and write to a simpler file name with no spaces, numbers, or special characters.

 

M

I am having the same problem. Could you provide an update from your support case when you find out the cause? Thanks!

W
Badge +1

I am having the same problem. Could you provide an update from your support case when you find out the cause? Thanks!

Nothing from support yet. I'll keep you posted.

 

Meanwhile, the workaround is working around the problem.

D

I struggled with similar issue as well. As a work around I had to use a FGDB writer instead of using featurewriter. Later I found out that my UNC path was outdated. Fixing the UNC and re-running solved it.

 

Another thing is to pay attention to the type of FGDB writer you end up selecting while configuring the featurewriter transformer. The open API fgdb writer is limited so one has to make sure about selecting the esri fgdb type.

 

Thanks,

Deep

( This is an updated version of my previous post here)

 

 

 

 

steveatsafe
Rank
Badge +11

Hi All,

I've been looking at this for evidence of what might be going on.

 

I'm suspecting network shares that have some sort of caching in place that might be introducing a latency for file creation/deletion, and FME doesn't wait or is being told something completed when it hasn't. I'm not sure... but I know in one instance there were as new file server added to an environment where a user started to experience this. Using the old file server there were no problems.

I'm curious to know if any of you could see if there have been changes to your file servers (network shares) that might help us explain this behavior and possibly reproduce this locally.

We have been able to reproduce an issue with the writer where deleting an existing GDB to replace it (overwrite) caused a problem, but then running the workspace a second time the workspace would complete successfully. I think again, there was a lag between the file being deleted (and likely locked), and FME attempting to create a new file (but couldn't because of the lock for delete).

But this doesn't happen in all cases. So I have to think it is the file server in the background that is a factor.

As user WillCad points out, when creating a new gdb file, a workaround is to use a template file. (see above in his updated question).

Looking forward to hearing about the file servers.

SteveatSafe
steveatsafe
Rank
Badge +11

Hi All,

I've been looking at this for evidence of what might be going on.

 

I'm suspecting network shares that have some sort of caching in place that might be introducing a latency for file creation/deletion, and FME doesn't wait or is being told something completed when it hasn't. I'm not sure... but I know in one instance there was a new file server added to an environment where a user started to experience this. Using the old file server there were no problems.

I'm curious to know if any of you could see if there have been changes to your file servers (network shares) that might help us explain this behavior and possibly reproduce this locally.

We have been able to reproduce an issue with the writer where deleting an existing GDB to replace it (overwrite) caused a problem, but then running the workspace a second time the workspace would complete successfully. I think again, there was a lag between the file being deleted (and likely locked), and FME attempting to create a new file (but couldn't because of the lock for delete).

But this doesn't happen in all cases. So I have to think it is the file server in the background that is a factor.

As user WillCad points out, when creating a new gdb file, a workaround is to use a template file. (see above in his updated question).

Looking forward to hearing about the file servers.

SteveatSafe

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.