Question

FGDB read error - the error number from ArcObjects is: '-2147220893'

  • 10 October 2019
  • 7 replies
  • 141 views
S
Badge

Hi, does anyone have any experience with the following error: -

"Unable to connect to the File Geodatabase at '------'. 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: '-2147220893'. The error message from ArcObjects is: {}

A fatal error has occurred. Check the logfile above for details"

 

We have recently just started receiving the error on all workbenches that are reading feature classes from a .fgdb. The error is inconsistent between what database it happens on and when (i.e. re-running workbench multiple times in a row, it may read a few times without issue). We have alot of automated processes that should run in the background that are now failing.

We are using FME 2018.1 via ArcGIS Pro Data Interoperability and have recently had a company wide roll out of windows 10 laptops.

I believe the issue is somehow related to the shared drive the data is stored on. As copying data to desktop or another server completely gets rid of the issue (but unfortunately this is not a workable solution). Our IT department is investigating, but they are not familiar and do not support GIS formats or FME....

If anyone has any idea or things I could point IT towards that would be great. Thanks.

 

 

7 replies

ebygomm
Rank
Userlevel 1
Badge +21

I've seen issues where if the filepath to the gdb is too long, FME cannot open the gdb correctly

bruceharold
Rank
Badge +16

Network Attached Storage technologies may cause issues, please work with Esri support.

S
Badge

I've seen issues where if the filepath to the gdb is too long, FME cannot open the gdb correctly

Interesting! What would be considered too long? Currently the gdb that fails most often is 43 characters long / 6 folders (which I didn't think was particularly long), moving it up a few folders has definitely stopped that error occurring today in my test workbench.

ebygomm
Rank
Userlevel 1
Badge +21

Interesting! What would be considered too long? Currently the gdb that fails most often is 43 characters long / 6 folders (which I didn't think was particularly long), moving it up a few folders has definitely stopped that error occurring today in my test workbench.

In our case, it wasn't just the length of the path to the gdb but the length of the featureclass names as well, but this was in excess of 260 characters. (and i think the 260 characters is not a limitation in windows10 anyway)

philippeb
Badge +8

Interesting! What would be considered too long? Currently the gdb that fails most often is 43 characters long / 6 folders (which I didn't think was particularly long), moving it up a few folders has definitely stopped that error occurring today in my test workbench.

Are you using UNC path or mapped drive ? If it's UNC, that can add a few characters to you path.

Example :

We used to have S:\\project

Now we have to use \\\\city.newyork.gov.usa\\services\\geographic\\project

I'm not the one who approved this change.

 

S
Badge

Are you using UNC path or mapped drive ? If it's UNC, that can add a few characters to you path.

Example :

We used to have S:\\project

Now we have to use \\\\city.newyork.gov.usa\\services\\geographic\\project

I'm not the one who approved this change.

 

We are using mapped drives for most of our data. Reducing the file path has definitely helped the issue. But must be the fact that its on network drive as well? As file paths on my desktop are considerably longer and I have never had an issue with those.

dallalana91
Badge

Hello there...

 

I'd find this article and works for me.

https://community.esri.com/t5/arcobjects-sdk-questions/error-workspace-or-data-source-is-read-only-from/td-p/505388

 

READ-ONLY at GDB folder

 

Cheers!!

 

Demetrius Dallalana

Reply


Community Stats

28,706
Posts
109,463
Replies
36,550
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.