Many applications (Crystal Reports, Excel, SQL Server etc.) are OleDB
consumers with built in support that allow non-DBA users to quickly and
easily retrieve data from sources that have OleDB providers. I have not seen
similar support for sources that only provide a Managed provider. ADO.NET
has been around for many years now.
Assuming the data is generated in a .NET application, how does Microsoft or
this community recommend exposing data to these OleDB consumer applications?
Is there a managed provider to OleDB interface conversion mechanism?
Background Info:
We were once a COM/C++ shop and are now small .NET shop. We have lost
virtually all of our COM/C++ experienced programmers. We have re-written the
original COM/C++ server as a .NET server. This server accesses multiple
sources, manipulates the data and exposes the results in the form of a
"DataView". In our past incarnation the organization used the ATL C++ sample
provided by Microsoft to build an Oledb provider that reads these DataViews
as OleDB Views, providing the schema information via schema rowsets. We have
client applications that read the schema rowset and data for these DataViews
and writes the data to CSV or XML files, and to Access, Excel and Word
files.
Having an OleDB provider provided two advantages. 1) the clients
applications could run without installing .NET on the client PC. and 2) The
client applications could also read other OLEDB wources using the same code
path as used for reading our DataViews.
This works well enough, but we now have clients that want to use our
propritary OleDB provider to access DataViews from CrystalReports (and other
applications that support OleDB.) Unfortunately these applications fail when
reading the data. Our organization is struggleing with very old (as far as I
know unsupported) ATL C++ code to fix this problem. Replacing this ATL C++
OleDB with a .NET solution would be highly desireable.
|