Net4x.DapperLibrary.OleDb 1.9.9.8

DapperLibrary.OleDb

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

Purpose

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

• OleDbDapperContext � a DapperContext configured for OLE DB and wired to configuration via DapperConfigurationManager.
• OleDbProviderFactory � configures parameter handling, data adapter event forwarding and command parameter preparation tailored for OLE DB semantics.
• OleDbDatabaseModel, OleDbDatabaseModelTypes and OleDbDatabaseEnumTypes � identifier delimiters, statement terminator, parameter naming and provider-specific type/string mappings.

Key types

• OleDbDapperContext

  • Derives from DapperContext and is initialized with OleDbProviderFactory and a DapperConfigurationManager that targets the System.Data.OleDb namespace.
  • Constructors accept an IConfiguration instance to pull connection strings and other configuration values.

• OleDbProviderFactory

  • Inherits from ProviderFactoryBase and delegates to OleDbFactory.Instance.
  • Uses ParameterModel.ParameterPrefix = "?" and ParameterModel.AddIndex = false to match OLE DB parameter conventions (unnamed positional parameters commonly represented as ?).
  • Sets AddPrefixInParameterName = false and provides a PrepareCommandParameters implementation that creates DbParameter objects, injects them into the command and formats the command text by replacing placeholders with parameter names.
  • Attaches to RowUpdated/RowUpdating events on the OleDbDataAdapter and forwards them via the provider factory.

• OleDbDatabaseModel and related types

  • Identifier delimiters: [ and ].
  • Batch terminator: ;.
  • Parameter prefix: ? and parameter base name: Par.
  • Type mapping strings are built around System.Data.OleDb.OleDbType names (for example Integer, BigInt, LongVarBinary, VarChar({0}), etc.).

Usage examples

Create and use an OleDbDapperContext:

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

The OleDbProviderFactory prepares command parameters by creating DbParameter instances and formatting the command text using parameter names (the provider uses positional ? parameters, so AddIndex is false by default in this factory).

Parameter conventions

• OLE DB typically uses positional ? parameters. The provider factory sets ParameterPrefix to ? and does not add an index to parameter names by default (AddIndex = false).
• PrepareCommandParameters builds parameters and then replaces indexed placeholders in the SQL command with the parameter names. This keeps parameter handling consistent with other providers in the DapperLibraries while accommodating OLE DB conventions.

Example of how values are bound in the provider:

• For a statement with placeholders like {0}, {1}, the factory will create parameters, add them to the command and then format the command text using the actual parameter names so the provider receives a command with ?-style parameters.

Multi-targeting & compatibility

• The project is intended to be usable on older .NET Framework targets (the solution contains many multi-targeted projects). The OLE DB provider types (System.Data.OleDb) are available in .NET Framework; when targeting .NET Core/.NET 5+ consider using ODBC or provider-specific clients if native OLE DB support isn't available for your runtime.
• The code contains conditional compilation in related projects across the solution to produce framework-specific binaries.

Synchronous vs asynchronous behavior

• OLE DB ADO.NET implementations traditionally have limited or no asynchronous I/O support. DapperLibrary exposes both synchronous and asynchronous APIs, but on platforms/providers without true asynchronous support the Async-suffixed methods may execute synchronously under the hood or use provider-specific async shims.
• Prefer synchronous APIs when targeting runtimes where the underlying OLE DB implementation lacks proper async support. Use async APIs in environments where the provider supports non-blocking I/O and you need to avoid blocking threads.

Events and adapter behavior

• OleDbProviderFactory.CreateDataAdapter attaches RowUpdating and RowUpdated event handlers and forwards these events via the provider factory. Consumers using DbDataAdapter-based save operations can subscribe to these events to customize row-level update behavior.

Notes and best practices

• Because OLE DB commonly uses positional parameters, avoid relying on named-parameter semantics when building raw SQL for OLE DB providers; rely on the PrepareCommandParameters conventions implemented by the provider factory instead.
• For new applications on modern .NET runtimes, consider provider choices (ODBC, native client libraries) if OLE DB provider support is limited on your target platform.
• Use the WithConnection overloads on DapperLibrary APIs to target specific named connections for single calls to avoid shared-state contention around ConnectionStringToRead.

For implementation details review OleDbProviderFactory, OleDbDapperContext and the DbContexts types in this project.