|     Blog    |     Wiki    |     Support

Replacing Access OLEDB provider with another in QueryTools.ExecuteQuery

As discussed here QueryTools.ExecuteQuery requires Microsoft.ACE.OLEDB.12.0 driver to work.

This introduce some problems for us.
Customers have different versions of office and we cannot install Microsoft.ACE.OLEDB.12.0 x64 when they have office x86 otherwise that would break their MS Word so we have to use x86 version of our application and that’d introduce performance issues.
Therefore we would prefer not to install the Access driver as the dependency for our product.

All that said, I’m wondering if it is possible to introduce our own provider for QueryTools.ExecuteQuery instead of the one it already uses?


Hi John,

Our developer did research for your requirement, it looks we hadn’t found a solution about how to custom set it without install system package. If you have some information about that please let us know, we can see whether we can implement that.

So what’s the problem faced if you debug your application under x86? If you debug it into x86 it should works because it load Microsoft.Jet.OLEDB.4.0 provider.



Dear Ethan,

It is more because we cannot install x86 access driver on customers machines due to its conflict with Microsoft Word.

I’m wondering how likely is it that ThinkGeo abstract QueryTools into another interface like IQueryTools so that we can introduce another implementation instead? If you think there is another way to replace this dependency in QueryTools, I would appreciate it if you could kindly share those with me.


Hi John,

As you know, QueryTools.ExecuteQuery requires Microsoft Access Driver to work. Windows system supports 32bit version Microsoft Access Driver default, and the 64bit driver isn’t supported. If users want to 64bit driver, users need to install 64bit Microsoft Access Database Engine Redistributable.
Microsoft Access Database Engine 2010 Redistributable:
Microsoft Access Database Engine 2013 Redistributable:
Microsoft Access Database Engine 2016 Redistributable:
They are system runtime libraries and compatible with Microsoft Word.

If you want to use another implementation instead of OLEDB, you can overwrite ExecuteQueryCore function of FeatureSource. For example:

class CustomShapeFileFeatureSource : ShapeFileFeatureSource
    protected override GeoDataTable ExecuteQueryCore(string sqlStatement)
        // Your implementation.

class CustomShapeFileFeatureLayer : ShapeFileFeatureLayer
    public CustomShapeFileFeatureLayer()
        FeatureSource = new CustomShapeFileFeatureSource();

CustomShapeFileFeatureLayer layer = new CustomShapeFileFeatureLayer();

If you have any questions, please feel free to contact us.


1 Like