Skip to main content
Question

Geodatabase error 2147467259 Could not read Field


Forum|alt.badge.img

Guys,

something wrong is going on. I was changing existing working workspace to pointing to new geodatabase zip file, which also has new table structure. Modified new workspace is working fine on my PC under FME Workbench.

But if I publish it on FME Server I'm getting the error (see below) for each attribute that we are not reading from geo tables. And since original database is huge after few minutes FME Server stops the job without any failure message and building core dump files on FME Server machine.

Error messages that we are getting:

Geodatabase Error (-2147467259): General function failure.

Could not read Field `column_name' in Table `Table_name'

Does somebody know where the issue can be?

Appreciate any help!

Thanks.

9 replies

david_r
Evangelist
  • March 28, 2018

Sounds like a corrupt geodatabase to me.

Also, make sure you're not using one of the reserved words in your table or feild names: https://support.esri.com/en/technical-article/000010906


Forum|alt.badge.img
david_r wrote:

Sounds like a corrupt geodatabase to me.

Also, make sure you're not using one of the reserved words in your table or feild names: https://support.esri.com/en/technical-article/000010906

Please explain: how could it be corrupted if it works fine on local PC under FME workbench? and the same geo file is used for FME Server

 

 


fmelizard
Contributor
Forum|alt.badge.img+17
  • Contributor
  • March 28, 2018
Are you using any python (arcpy) in the workflow? There is a known issue with ArcGIS Server and arcpy.

 

When adding the new data did you use the 'Update Reader' Have you tried deleteing and readding the reader fresh as a test?

 

 


Forum|alt.badge.img
david_r wrote:

Sounds like a corrupt geodatabase to me.

Also, make sure you're not using one of the reserved words in your table or feild names: https://support.esri.com/en/technical-article/000010906

example of issue:

 

Could not read Field `stfeat' in Table `AM_ApronElement'

 

reserved words are not in use

 

 


Forum|alt.badge.img
fmelizard wrote:
Are you using any python (arcpy) in the workflow? There is a known issue with ArcGIS Server and arcpy.

 

When adding the new data did you use the 'Update Reader' Have you tried deleteing and readding the reader fresh as a test?

 

 

arcpy is not in use

 

 

I created fresh workspace with a copy of failed reader with failed attributes and that workspace was working fine in FME Server

 

 


trentatsafe
Safer
Forum|alt.badge.img+6

Hi @alexanderyanush,

A couple questions(to test on the Server machine):

1) Do you have a secondary table inside that Geodatabase that you can read from? Does it function the exact same?

 

2) Are you able to write to a new table in that existing Geodatabase?

 

3) Are you able to share the geodatabase/table that is causing issues?


david_r
Evangelist
  • March 29, 2018
alexanderyanush wrote:
Please explain: how could it be corrupted if it works fine on local PC under FME workbench? and the same geo file is used for FME Server

 

 

How are you publishing the dataset? Upload or file copy? Zipped or not? If zipped, try dezipping before reading it into FME.

 

 

If you're using the GEODATBASE_FILE reader, also try using the FILEGDB reader, or vice versa.

Forum|alt.badge.img
david_r wrote:
How are you publishing the dataset? Upload or file copy? Zipped or not? If zipped, try dezipping before reading it into FME.

 

 

If you're using the GEODATBASE_FILE reader, also try using the FILEGDB reader, or vice versa.
We did upload a zip. I have tried to upload unziped data and got the same issue.

 

We are using FILEGDB and we have tried GEODATBASE_FILE.

 

 

Also I found that the issue is caused only by attributes that have date datatype!

 


david_r
Evangelist
  • March 29, 2018
alexanderyanush wrote:
We did upload a zip. I have tried to upload unziped data and got the same issue.

 

We are using FILEGDB and we have tried GEODATBASE_FILE.

 

 

Also I found that the issue is caused only by attributes that have date datatype!

 

That's really strange, I agree. Sounds like a case for Safe support.

 


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings