"TC" <T*@professionalDevel.com> wrote in message
news:6D426EB4-9357-4D6C-82B1-8CC6ACC6DFF7@microsoft.com...
> 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?
>
>