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?

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.

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.

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)

Hi All,

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

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.

Hi All,

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

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.