We have many places in our code where we use ExecuteQuery with ShapeFileFeatureLayers. From another post I see that this feature is no longer supported. Is there a recommended workaround? I was thinking If I wanted to accomplish the query i might be able to do so by converting the dbf data to a standard DataSet, but I would prefer not to have to do that.
Thanks!
Steve
Hi Steve,
You’re right that ExecuteQuery was dropped from ShapeFileFeatureLayer. The original implementation read the .dbf companion through System.Data.OleDb with the Microsoft.Jet.OLEDB.4.0 provider, which is for Windows-only and doesn’t exist on .NET Core +, so we removed it during the cross-platform migration from v12.
You can subclass ShapeFileFeatureSource and wire OleDb back in for a Windows-only project, but the deployment story is rough: Jet 4.0 was never built for x64, and the 64-bit alternative (ACE 12.0) needs every end-user machine to have the Microsoft Access Database Engine Redistributable installed at the matching bitness. The only “no-install” path is forcing x86, with the 32-bit address-space ceiling. Most
customers can’t accept that anymore.
So converting the dbf data to a standard DataSet is not a bad idea. Also ThinkGeo.Gdal exposes the .dbf through OGR with its own SQL engine, you can try that as well if you already using gdal in the project.
var layer = new GdalFeatureLayer(@"places.shp", "places");
layer.Open();
DataTable dt = layer.QueryTools.ExecuteQuery("SELECT * FROM places WHERE POP > 50000");
Thanks,
Ben