Custom ADO.NET Data Provider from MFC legacy DAL?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Background:
We have a legacy DAL which was written for our MFC applications. It accesses
one of two databases depending upon what data the client needs (Oracle or
Sybase). It returns a CRecordset derived class to the client, so depending
upon whether the client is currently pointing to Oracle he gets the Oracle
data and vv with the Sybase data. This part works ok in the MFC world.

Problem:
We now have new applications which are written in .NET. These new
applications are currently using ADO.NET to access their data. The new apps
need to throw away their databases and begin to use our data sources (Oracle,
Sybase with the MFC wrapper for DAL). We don't want to rewrite a bunch of the
client code on the new apps, so we thought we could create a custom ADO.NET
provider.

In our prototyping, we came up with a COM wrapper for the legacy DAL which
can be imported using tlbimp into a .NET project. This part looks ok, but it
does not look like ADO (it looks like COM Collection classes).

So we created an ADO.NET Data Provider, which imports the COM Wrapper and
iterates the COM Collection to create an IList resultset for the DataReader
and the DataSet.

This kind of works, but we're going to be accessing 100k+ records at a time
so performance is horrible! This is because 1) we iterate the CRecordset to
pack into the COM Collection 2) Unpack the COM Collection in the ADO.NET
Provider 3) Unpack the COM collection into the IList in the provider for
return from the Data Reader and Data Adapter.

So, we are looking for ideas on solving this problem of mapping an existing
MFC DAL into the ADO.NET world. Anyone else had this problem?


Thanks,

-Tony
 
TC said:
Background:
We have a legacy DAL which was written for our MFC applications. It
accesses
one of two databases depending upon what data the client needs (Oracle or
Sybase). It returns a CRecordset derived class to the client, so depending
upon whether the client is currently pointing to Oracle he gets the Oracle
data and vv with the Sybase data. This part works ok in the MFC world.

Problem:
We now have new applications which are written in .NET. These new
applications are currently using ADO.NET to access their data. The new
apps
need to throw away their databases and begin to use our data sources
(Oracle,
Sybase with the MFC wrapper for DAL). We don't want to rewrite a bunch of
the
client code on the new apps, so we thought we could create a custom
ADO.NET
provider.

In our prototyping, we came up with a COM wrapper for the legacy DAL which
can be imported using tlbimp into a .NET project. This part looks ok, but
it
does not look like ADO (it looks like COM Collection classes).

So we created an ADO.NET Data Provider, which imports the COM Wrapper and
iterates the COM Collection to create an IList resultset for the
DataReader
and the DataSet.

This kind of works, but we're going to be accessing 100k+ records at a
time
so performance is horrible! This is because 1) we iterate the CRecordset
to
pack into the COM Collection 2) Unpack the COM Collection in the ADO.NET
Provider 3) Unpack the COM collection into the IList in the provider for
return from the Data Reader and Data Adapter.

So, we are looking for ideas on solving this problem of mapping an
existing
MFC DAL into the ADO.NET world. Anyone else had this problem?
Click to expand...

Well you don't have to copy the data into the IList. Just provide an IList
implementation that accesses teh data in the MFC CRecordset. This will cut
out one copy. However if the .NET application wants a DataSet, you will
still have to copy the data into the DataSet.

But your root problem is accessing 100k+ "records" at a time in the client.

David
 
Back
Top