Creating a connector that uses a native component / ADBC

Hi SQLGuy ,

You've run into an advanced and sparsely documented part of Power BI development. There is no simple, official way for a standard M-based custom connector to directly use the libadbc_driver_flightsql.dll you've found. The M language is sandboxed and can't just call native DLLs. The dll exists because Microsoft's own internal connectors can be built with C# and have the ability to call native libraries for better performance, a feature not fully exposed in the public SDK.

One potential but highly complex path is to create a native connector. This involves building a C# assembly that Power BI's Mashup Engine can load. This C# code would then use Platform Invocation Services (P/Invoke) to load libadbc_driver_flightsql.dll and call its functions. The C# code then exposes its own functions that your M script can call, effectively creating a wrapper. Since this is undocumented, your best bet for learning is to explore the Microsoft DataConnectors GitHub repository. By analyzing the C# source code (.cs files) of official connectors like the Odbc one, you can see how they use [DllImport] attributes to bridge the gap between .NET and native code.

A much more practical and recommended approach is to use an ADBC-to-ODBC bridge 🔗. This is an ODBC driver that translates standard ODBC calls into ADBC calls behind the scenes. For your Power BI connector, this means you can ignore the ADBC driver completely and simply build your connector around the standard, well-documented Odbc.DataSource function. Your M code would look something like this, treating the ADBC source as just another ODBC connection:

[DataSource.Kind="MyFlightSQLConnector", Publish="MyFlightSQLConnector.Publish"]
shared MyFlightSQLConnector.Contents = (dsn as text) =>
    let
        Source = Odbc.DataSource("dsn=" & dsn, [HierarchicalNavigation=true])
    in
        Source;

While the native connector path offers the highest potential performance, it is incredibly complex and relies on unsupported, undocumented features. In contrast, using an ODBC bridge is vastly simpler, more stable, and uses standard Power BI functionality. I strongly recommend pursuing the ODBC bridge path. The development effort is significantly lower, and the result is far more maintainable.

Best regards,