Skip to main content
  • EN
  • Home
  • Forums
  • FME Flow
  • Automation
  • FME server refuses to connect to a .gdb running a workbench that runs on desktop on my PC and on the server. The dreaded arcobjects error -2147024893

I have arcgis pro only on my pc. The FMEServer machine also has Pro only. I am able to successfully run a workbench that accesses .gdb's to read/write on my desktop and on the server desktop. However, when I publish to server and try to run from the repo or with an automation, I get the following error.

 

Unable to connect to the File Geodatabase at 'XXXXXXX.gdb'. Make sure the correct filename was specified, and that the Geodatabase wasn't saved with a newer version of ArcGIS than the one installed locally. The error number from ArcObjects is: '-2147024893'. The error message from ArcObjects is: {}

 

I have forced the workbench to translate as 'Pro' instead of auto. The Pro licence on server is authed correctly. FME desktop and server versions are 2022.1 and 2022.1 respectively and the .gdbs were created prior to these versions of FME being used so there is no issue there.

 

I have also had this error at another workplace and it is driving me crazy.

 

Any potential solution would be welcomed as I cannot run any automations in the meantime.

 

Thanks,

 

Brady

 

 

Are you reading from and writing to the same file geodatabase in the same workspace? Then I suspect you are locking it, preventing workbench to do it's thing. This might work on desktop using featurecaching, because you are working step by step through it, but not when featurecaching is turned off, as on server.

Are you reading from and writing to the same file geodatabase in the same workspace? Then I suspect you are locking it, preventing workbench to do it's thing. This might work on desktop using featurecaching, because you are working step by step through it, but not when featurecaching is turned off, as on server.

no, read one .gdb and push to AGOL

OR

read from one .gdb and write to another .gdb

 

I rarely use featurecaching.

 

I don't think it's a locking issue. That is usually a different error. Thanks for the reply 🙂

no, read one .gdb and push to AGOL

OR

read from one .gdb and write to another .gdb

 

I rarely use featurecaching.

 

I don't think it's a locking issue. That is usually a different error. Thanks for the reply 🙂

Might it be a permissions issue then? We had some issues with files created by users which could not be edited by the fme server user, it not being the owner. Removing the user created files and let them be created by the fme server user solved this.

no, read one .gdb and push to AGOL

OR

read from one .gdb and write to another .gdb

 

I rarely use featurecaching.

 

I don't think it's a locking issue. That is usually a different error. Thanks for the reply 🙂

worth taking a look 🙂 thanks for the suggestion

Reply


Community Stats

30,351
Posts
115,341
Replies
38,081
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.