The .NET Data Provider offers a series of .NET types to describe the user's data, .NET provider classes to manipulate the data, and connection pooling to efficiently manage data connections.

The design and naming conventions of the .NET Data Provider's data types, classes, properties, and methods follow the same pattern as the Microsoft .NET Data Providers. Consequently, developers who are familiar with the Microsoft providers can easily develop or convert existing code from Microsoft databases to Actian databases.

All .NET Data Provider modules are written in C#, a managed .NET language with full access to every .NET Framework capability. Even though the data provider is written in C#, any managed language such as VB.NET or J# can use the data provider because of .NET's language interoperability feature.

A data provider in the Microsoft .NET Framework enables a connection to a data source to retrieve and modify data from that data source. Data coming out of a .NET data provider can be used directly by an application or it can be redirected into an ADO.NET DataSet where it can be processed by other application methods such as XML processing.

The following figure shows the flow of data in and out of the data provider.

As shown in this figure, the .NET Data Provider uses an intermediate server called the Data Access Server to access Actian databases.

For additional information on this server, see the chapter "Configuring the Data Access Server."

The .NET Data Provider includes a client assembly that contains the base runtime support. In version 3.x and later the client assembly is named Actian.Client.dll. In previous versions, it is named Ingres.Client.dll.

The .NET Data Provider includes the Ingres.Client.dll, which contains the Ingres.Client assembly. The Ingres.Client assembly contains the base runtime support.

The .NET Data Provider 3.x is packaged in a NuGet package (with suffix .nupkg), which is the Microsoft standard for managing dependencies across .NET projects and applications. The package includes both a “net45” library for .NET Framework applications and a “netstandard2.0” library for .NET Core applications. The package can be installed into a local or private NuGet feed for easy access to build and run applications. The package may become available in the future on a public NuGet feed.

Optionally, the .NET 4.5 data provider (net45) assemblies Actian.Client.dll and Actian.Support.dll can also be installed into the Global Assembly Cache (GAC) by unzipping the package and installing the DLL into the GAC. The .NET Standard version can be installed into a .NET runtime package store. The preferred and standard approach, however, is to reference the .NET Data Provider via NuGet.

For the 2.x version of the .NET Data Provider, the assembly is installed as part of a standard Actian client installation, which automatically registers it in the Global Assembly Cache (GAC). The Ingres.Client.dll assembly is also installed, by default, into the directory C:\Program Files\Ingres\Ingres .NET Data Provider\v2.1.

When developing .NET applications, programmers use the data types, components, and other classes in the data provider by referencing each name as defined in the namespace for the classes. The namespace for the .NET Data Provider, regardless of version, is:

Because the namespace is the same across versions of the .NET Data Provider, applications written for older versions should be compatible with the latest version of .NET Data Provider.

The .NET Data Provider provides ADO.NET programmers with two access strategies for retrieving data:

In addition to the low-level DataReader and DataAdapter access strategies, the data provider works with Visual Studio to support TableAdapter, DataConnection, and DataSource components. The data provider uses standard base classes, interfaces, and metadata methods to support higher level data-bound .NET Framework controls. .NET Framework and Visual Studio work with the .NET Data Provider to offer more rapid application development and high quality code.

Connection pooling significantly enhances the performance and scalability of some applications. Physical connections are kept in a pool after they are no longer needed by one application and are dispensed later to the same or another application (as needed) to avoid the cost of connections. All connections in a pool have identical connection strings. A new pool is created for each connection that has a different connection string from all other pools.

When an application attempts to connect to a database, the Open method of the IngresConnection object uses the connection pool to search for a physical connection that specifies the same ConnectionString parameters. If no match is found, a new physical connection is made to the database. If a match is found, a connection is returned to the application from the pool.

After the application has completed its work, committed its changes, freed its database locks and resources, and closed the connection, the physical connection is retained by the .NET data provider and placed back in the connection pool instead of being physically disconnected.

This connection is available to the same application later in the application's life span or to other applications in the same process with the same connection parameters. This avoids the overhead and delay of opening a new physical connection. An application can choose to disable connection pooling by specifying “Pooling=no” in its connection string.

The application is unaware of the connection reuse. If the connection is not reused within sixty seconds, the connection is physically closed to release system resources.

However, if the number of connections in the pool falls below the minimum number of connections specified by the application in the “Min Pool Size=n” value in the connection string, the connection is not physically closed and is retained in the pool for later use. For additional information on connection pooling, see IngresConnection Class.