ThinkGeo.com    |     Documentation    |     Premium Support

File GeoDatabase Table Read Error

#1

Hi All,



I have problems reading some types of tables in various File GeoDatabases.  Attached is such an example.



The inner exception just says “General function failure”.



Can you please try and load the attached database and see what the problem is?



I am using build 6.0.0.371.



Thanks,

Damian

Wells_GMX.gdb.zip (1.65 MB)

#2

Hi Damian, 
  
 Sorry my environment updated, so I my quickly test can only work for 7.0 first.  
  
 Here is my inner exception: {“The table was not found.”} . And my test code is: 
  
 fileGeoDatabaseFeatureLayer = new FileGeoDatabaseFeatureLayer(@"…/…/data/Wells_GMX.gdb", “Wells_GMX”); 
  
 That’s strange because the FileGeoDatabaseFeatureLayer.GetTableNames(@"…/…/data/Wells_GMX.gdb") function shows your data only contains one table. 
  
 I am not sure whether it is an issue or have a data broken, I will takes much more time on it tomorrow. 
  
 If possible please try to use newest version, because it looks the FileGeoDatabase related dlls in systemWow64 have been updated this time. 
  
 Regards, 
  
 Don

#3

Hi Don, 
  
 I’ve upgraded to 7.0 and also ran the unmanaged assemblies .msi.  Does that update the SysWOW64 and System32 directories?  If so, then I am up to date on the dll’s through 7.0.0.42. 
  
 I got the same error with this database as you.  However, my GIS guy using ArcGIS can still open the database and work with it.  So, it is really important that I be able to do the same. 
  
 I’ve also found another database table that refuses to open which yields a TargetInvocationException saying the table was not found even though it was returned from the GetTableNames() command.  Again, the GIS guy can read this data in just fine in ArcGIS.  I will have to send you this example table tomorrow though as it’s currently wrapped in a much larger proprietary database and we need to make an extract for you. 
  
 Regards, 
 Damian

#4

Oh, I forgot to mention as well.  In your post, you input the incorrect table name which is why you get the Table not Found exception.  The GetTableNames() command should show you that the name of the table in the first database is simply WELLS. 
  
 fileGeoDatabaseFeatureLayer = new FileGeoDatabaseFeatureLayer(@"…/…/data/Wells_GMX.gdb", "Wells"); 
  
 Once you change that, then you should get the same error as I do when trying to query the feature source using GetAllFeatures. 
  
 Regards, 
 Damian

#5

Hi Daminan,



Thanks for reporting this,



About “General function failure”, we tried to recreate it, but it didn’ show up, following is a snip of our test, would you please check it and tell us what we missed?



About the “Table not found”, we have recareated it in your another post, and it is recreated and will need a little while to sort it out, any thing new will be updated in that post.



Sorry for your inconvenience



Don

#6

Hi Don, 
  
 Sorry, I confused the error messages with the 2 posts.  The TargetInvocationException is what I am expecting for the Wells table. 
  
 When I experienced the error, I was iterating through the features in the layer using FeatureSource.GetAllFeatures() method. 
  
 I have found that if I limit my query using FeatureSource.GetFeaturesInsideBoundingBox() and submit the maps viewable area as the bounding feature, then I can work with the subset of features in the table.  This seems to indicate that there must be some bad data points in the table.  However, I think that FeatureSource.GetAllFeatures() query should not simply fail, but rather just ignore features which don’t fit the basic shape requirements.  That way, I can examine features without fear of failure. 
  
 Can that change be made so I can regularly query the FeatureSource without fear of returning errors for the entire table?  Can you actually isolate the data points and say what the reason for the failure is? 
  
 You are quite right about my other post.  I made the new post because I realized it was a different issue altogether and didn’t want to mix the two. 
  
 Thanks, 
 Damian  
  
 Thanks, 
 Damian

#7

Hi Damian,



We have replied it in thinkgeo.com/forums/tabid/14…fault.aspx, would you please get the check it there?



Hope it helps



Summer