Connect to IBM i (AS/400) using .NET?

How to connect to an IBM i (AS/400) system from a .NET application? It’s still a question many teams are asking themselves, whether developers or technical managers. The answer lies in one solution: NTi Data Provider.

image illustrating article

Traditionally, the go-to approach has been to rely on external drivers like ODBC or OleDB. While often free and still in use, these solutions have long been serviceable. IBM’s DB2 Connect is another option more complete, but costly and complex to set up. However, all of these rely on native compiled code for each architecture and run outside the CLR (.NET Common Language Runtime). The result? Incomplete integration into the .NET ecosystem, limited strictly to the database, with environment-specific dependencies and reduced application portability.

Comparison between ODBC/OleDB/DB2 Connect and NTi Data Provider to connect IBM i with .NET

NTi brings a different, truly modern approach. Entirely based on the .NET CLR, it is cross-platform (Windows, Linux, macOS) and requires no external dependency. No installation is needed on the IBM i side, everything runs inside the .NET environment, like any other provider.

Access is therefore no longer limited to DB2 for i: you can run CL commands, call RPG programs, and more generally access all IBM i resources using standard .NET syntax. To date, you will not find any equivalent on the market that offers this level of integration between .NET and IBM i.

NTi Data Provider cross-platform: ARM64, AMD64 and ppc64le compatibility with .NET

Connection.

In practice, connecting to IBM i works like with any other DBMS supported by .NET. The key difference is that this is a dedicated ADO.NET provider for IBM i, AS/400, iSeries, designed and optimized for DB2 for i. In other words, the principle is exactly the same as for other databases:

  • For SQL Server, you use SqlConnection.
  • For PostgreSQL, you use NpgsqlConnection.
  • For IBM i, you use NTiConnection.

The code structure is identical, whether opening a connection or executing an SQL command. The only difference lies in the class used and the connection string, everything else relying on the standardized ADO.NET model.

Install the NuGet packages.

In Visual Studio, open the console and install:

Install-Package Aumerial.Data.NTi

Basic connection.

using Aumerial.Data.Nti;
using var conn = new NTiConnection("server=myIBMi;user=myUser;password=myPassword;");
conn.Open();

 try
 {
     conn.ExecuteClCommand("CRTLIB LIB(MYLIB) TEXT('new library')");
 }
 catch(NTiException ex)
 {
     Console.WriteLine(ex.Message);
 }
 conn.Close();

If you know SqlConnection, you already know NTi. This ensures immediate adoption for any team already skilled in .NET, without requiring specific IBM i expertise.

New features and connection properties.

NTi has evolved in its latest versions to meet the performance and security needs of modern applications, as well as the expectations expressed by our customers. These features are activated directly in the connection string, alongside the usual server, user and password parameters.

Since version 3.2.3, a connection pool has been available and enabled by default. Concretely, IBM i sessions are reused instead of creating a job (QZDASOINIT) for each request, drastically reducing response times and improving application scalability, particularly with Entity Framework Core.

Security has also been enhanced with support for multi-factor authentication (MFA) starting with version 4.4.0. NTi leverages the TOTP mechanism introduced by IBM in version V7R6 of its OS. A one-time code can be passed directly in the connection string or retrieved via a callback, making it easy to integrate MFA into existing .NET applications.

This topic is also at the heart of current events: it was widely discussed during the Securit.i 2025 edition, the reference event for IBM i security, where V7R6 updates and MFA held a central place. With NTi, this evolution is already available and operational in your .NET projects.

It should also be noted that NTi establishes the connection to IBM i through standard TCP/IP channels, relying on the system’s usual services:

  • QZDASOINIT for the database
  • QZRCSRVS for programs and commands
  • QZSOSIGN for Sign-on

It's possible to enable an encrypted SSL/TLS connection with a simple parameter in the connection string, ensuring that exchanges between the .NET application and IBM i remain protected. SSL configuration must obviously be carried out beforehand to establish this type of connection.

Entity Framework Core with NTi.

Entity Framework Core (EF Core) is Microsoft’s official data access framework for .NET. It provides an abstraction layer that allows data to be manipulated directly through C# (LINQ), without writing explicit SQL.

With the EF Core extension available with NTi, you benefit from this standard approach but tailored to DB2 for i. Your business logic remains entirely in C#, and SQL queries are automatically generated toward IBM i. Two approaches are possible, depending on your needs:

  • Database First (DB First): from existing DB2 for i tables and schemas, you directly generate your C# entities. This is the ideal solution for modernizing a production database without disrupting business teams.
  • Code First: you define your entities directly in C#, and EF Core creates the corresponding structure in DB2 for i, with automatic mapping of the correct types. Ideal for new projects.

All standard operations are covered: create, read, update, delete (CRUD) as well as joins, aggregations, pagination, or parameterized queries. The .NET developer remains within a consistent framework, without having to worry about DB2 for i specifics.

Example:


var ctx = new ProductDbContext();
string filter = "PROD";

var data = ctx.Products
              .Where(p => p.Label.Contains(filter))
              .Select(p => p.Label.Trim())
              .ToList();

Automatically generated on IBM i:

SELECT TRIM(p.Label)
FROM Products AS p
WHERE POSITION(@__filter_0, p.Label) <> 0

The latest version of the extension goes further by adding precise mapping of native DB2 for i scalar functions. Concretely, when a developer uses common C# methods (strings, numbers, etc.), they are translated into DB2 for i-typed SQL instructions. Calculations and transformations are therefore no longer simulated in .NET, but executed directly by DB2 itself on IBM i. And since it is designed to handle and process heavy workloads with reliability, it is the best place to delegate these operations in order to guarantee accurate results and optimal performance.

Conclusion.

The future cannot be built with tools of the past. Historical drivers may have served you well for years, but today they clearly show their limits whenever evolution, cloud, containers, or portability are at stake. Continuing to rely on them means choosing growing technical debt and postponing tomorrow’s problems.

With NTi, change perspective: choose a native, stable, and secure .NET connector, designed and built to integrate naturally into your .NET/IBM i projects over the long term.

So, if the question remains — How to connect your IBM i (AS/400) to .NET? — the answer is now obvious: not with software patches, but with the best solution currently available on the market. And the best way to be convinced is still to try it.

Request your NTi trial license today and see the difference for yourself..


Quentin Destrade