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,

Thanks. I'm working with Deephaven, which is a column-oriented DB that handles very large datasets. Preserving native driver performance is important for the final solution here. An ODBC wrapper for ADBC drivers would be handy for an interim solution and prototyping, but I am not aware of one that currently exists. I saw a link icon in your response, but it does not seem to go anywhere.

I had already looked through the examples in GitHub. I do not see any C# code there. I was hoping to see one of the Microsoft ADBC connectors, like the Snowflake one. Note that the  libadbc_driver_flightsql.dll is part of the current PowerBI distribution, though no connectors seem to yet use it.

Cheers,

Paul