Usage examples

Create and use an OleDbDapperContext:

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.