How To
Mimer Provider Manager - The solution for ADO.NET!
Categories: ADO.NET, Tools and Interfaces

ADO.NET is Microsoft's "standard" database interface in the .NET programming environment. This interface has many merits and makes it easier to build database applications compared to the older ADO interface.

However, there is one fundamental difference between the new database interface and the previous interfaces. The application is locked to the database with which it is compiled. What this means is that it is no longer possible to switch to another database without changing and recompiling the application.


The Mimer Provider Manager (Mpm) gives independence with the actual ADO.NET provider used, by offering a runtime ADO.NET provider dispatcher. It also gives the opportunity to enable SQL filters and a trace facility in the interface.

Mpm is very well integrated with the Microsoft Visual Studio. Documentation, wizards and stubs are available to facilitate for the programmer.

The product is 100% .NET managed.

What is the Mpm solution?

By using the Mimer Provider Manager, applications that are developed can be used with any underlying ADO.NET provider supported. New providers can easily be added to Mpm, usually without any programming. The architecture of the Mimer Provider Manager is shown in the following figure:

The actual provider used, is decided when the application connects to the database. This gives a number of benefits:

  • It is possible to develop generic applications that can be used with many underlying databases. For front-end tools this is an absolute necessity.

  • It is possible to try out the most efficient provider, when more than one exists, for a database server. This can be done as new providers become available. In an upgrade scenario it is possible to try new releases of a provider and revert back to the old version if desired.

  • The application will not be locked to one vendor. Many applications are ported between database systems even when this was not a requirement to begin with.

  • The application will not "by mistake" use a provider specific feature that makes migration expensive or not possible.

  • Different solutions and database brands can be benchmarked against each other. This lets the customer pick the system with the best price/performance.

The use of a Provider Manager has been the natural and proven way to achieve openness in earlier database interfaces, such as OLE DB and ODBC. The drawback is a minor cost in memory footprint and performance. This is far outweighed by the numerous benefits.

In addition, features called SQL Filters can be added to the Mimer Provider Manager. A filter works with the SQL statements passed by the application to the provider. One use of a filter can be to restrain the SQL used. For example, only SQL that complies with the SQL-99 ANSI SQL Standard may be accepted, to further enhance portability. Another possible use of SQL filters is to let the filter translate from standard SQL to a vendor specific SQL dialect, as shown in the picture below.


At our Mpm Documentation Page you will find documents that can give you details of the concept, the application use and everything you need to know for programming with the Mimer Provider Manager.
Last updated: 2004-06-08


Powered by Mimer SQL

Powered by Mimer SQL