ADO.Net and third-party drivers

ADO.Net and third-party drivers#

Querona supports ADO.Net as a general data-provider technology. A standard ADO.Net connection string can configure a connection to any data source that has an ADO.Net driver, so ADO.Net is the path Querona uses to reach the long tail of sources that do not have a built-in (native) provider — many SaaS, CRM, ERP and accounting systems.

Note

We recommend ADO.Net as the preferred generic technology. For sources that are already built into Querona (SQL Server, Oracle, MySQL, PostgreSQL, REST, JSON, XML and more), use the native provider instead — see Data sources.

Where to find drivers#

When a data source has no built-in Querona provider, you reach it with an ADO.Net driver you install. There are two places to get one:

  • The data source’s own vendor — the company that makes the database or application — where it publishes a driver. This is usually a standard, freely-distributable driver, so prefer it when it exists.

  • A commercial connector from a third-party driver vendor — for example CData, Devart or Progress DataDirect — covering the long tail of SaaS, CRM, ERP and database sources that have no free driver.

Important

Commercial drivers are not bundled with Querona and are licensed separately by their vendor. Install and license the driver according to the vendor’s terms before configuring the connection. A built-in provider or a standard driver is the out-of-the-box path.

Connect with an ADO.Net driver#

  1. Install the driver on the Querona host, following the vendor’s instructions, then restart Querona so the new driver is loaded. This affects the whole instance, so install and validate a new driver on a test environment first — never straight into production.

  2. Prepare a SQL dialect for the driver. Querona reads a source’s schema and decides what to push down through a SQL dialect (connection-string template, schema analyzer, query/SQL feature flags, type and function mappings). It ships dialects for the common providers, but a new or exotic ADO.Net driver needs its own. Unlike JDBC — whose drivers expose their metadata through a standard interface Querona can interrogate automatically — ADO.Net drivers report metadata and capabilities inconsistently, so an ADO.Net dialect is configured by hand (a custom schema analyzer rather than the automatic JDBC one).

    Tip

    Building a SQL dialect is an advanced topic: it governs how Querona reads metadata from the source and what it can push down, and it needs administrative access (Administer ‣ SQL Dialects). Where possible, start from an existing dialect for a similar source rather than from scratch. See SQL Dialects.

  3. Add the data source connection using that dialect and supply the driver’s ADO.Net connection string — see Create a connection.

Where a source needs source-specific setup (for example OAuth or a vendor SDK), that detail is documented on the source’s own page in Data sources.

See also#