Net4x.DapperLibrary.Odbc 1.9.9.26271

DapperLibrary.Odbc

ODBC provider integration for DapperLibrary. This project provides an ODBC-specific DapperContext implementation, a provider factory and database model/type mappings suitable for ADO.NET ODBC providers.

Purpose

Provide ODBC engine-specific behavior while preserving the common DapperLibrary API. The assembly includes:

• OdbcDapperContext � a DapperContext wired to ODBC via OdbcProviderFactory and DapperConfigurationManager for System.Data.Odbc.
• OdbcProviderFactory � configures parameter handling, command parameter preparation and adapter events for ODBC semantics.
• OdbcDatabaseModel, OleDbDatabaseModelTypes and OdbcDatabaseEnumTypes � identifier delimiters, statement terminator, parameter naming and provider-specific type mappings.

Key types

• OdbcDapperContext

  • Derives from DapperContext and can be constructed from an IConfiguration instance.
  • Uses OdbcProviderFactory to create provider-specific behavior and maps configuration via DapperConfigurationManager.

• OdbcProviderFactory

  • Inherits from ProviderFactoryBase and delegates to OdbcFactory.Instance.
  • Uses ParameterModel.ParameterPrefix = "?" and ParameterModel.AddIndex = false to match ODBC positional parameter conventions.
  • Implements PrepareCommandParameters to create DbParameter instances, add them to the command and format the command text with parameter names.
  • Attaches to RowUpdated/RowUpdating events on OdbcDataAdapter and forwards them.

• OdbcDatabaseModel and related types

  • Identifier delimiters: [ and ].
  • Statement terminator: ;.
  • Parameter prefix: ? and parameter base name: Par.
  • Type mapping uses OleDbDatabaseModelTypes in this project for string/type templates and OdbcDatabaseEnumTypes for ODBC-specific enum values (for example OdbcType.VarChar, OdbcType.Int, OdbcType.Date, etc.).

Usage examples

Create and use an OdbcDapperContext:

var configuration = /* IConfiguration with connection strings */;
using var context = new OdbcDapperContext(configuration);
// use context.Operations / context.Schema / context.SaveDataTable etc.

The OdbcProviderFactory prepares command parameters by creating DbParameter instances and formatting the command text so that ODBC providers receive a command with positional ? parameters.

Parameter and placeholder conventions

• ODBC uses positional ? parameters. The provider factory sets ParameterPrefix to ? and disables index-based naming (AddIndex = false).
• PrepareCommandParameters will create parameters, add them to the command and then replace placeholders like {0} with the actual parameter names.

Example flow:

• SQL with placeholders: SELECT * FROM Table WHERE Id = {0} AND Name = {1}
• Factory creates parameters ? and injects them into the command, then formats the command text to: SELECT * FROM Table WHERE Id = ? AND Name = ? (or provider-specific named parameters depending on provider behavior).

Multi-targeting & compatibility

• The project is included in a multi-targeted repository with many framework targets. System.Data.Odbc is available on .NET Framework and certain .NET Core/.NET runtimes�ensure your target runtime supports ODBC if you plan to use this provider.
• Conditional compilation across the solution allows producing framework-specific binaries where necessary.

Synchronous vs asynchronous behavior

• ODBC ADO.NET implementations historically have limited async support. DapperLibrary exposes both synchronous and asynchronous API variants, but on platforms/providers without true async support, the Async methods may operate synchronously internally.
• Use synchronous APIs for runtimes/providers without reliable async support. Prefer async APIs when the underlying driver supports asynchronous I/O and you need non-blocking behavior.

Events and data adapter behavior

• OdbcProviderFactory.CreateDataAdapter wires RowUpdated and RowUpdating to forward adapter lifecycle events. Consumers that use DbDataAdapter-based save operations can subscribe to these events to customize row-level behavior.

Notes and best practices

• Because ODBC commonly uses positional parameters, avoid relying on named-parameter semantics; rely on the provider factory's PrepareCommandParameters behavior.
• Use the WithConnection overloads when executing operations against a different named connection for a single call to avoid contention around ConnectionStringToRead.
• For modern .NET applications where ODBC is not preferred, consider provider-specific clients (e.g., Npgsql, Microsoft.Data.SqlClient) for better async support and richer provider features.

For implementation details consult OdbcProviderFactory, OdbcDapperContext, and the DbContexts types in this project.