Hi,

I would like to have a data layer that is independent from the data provider
and ADO.NET. What I mean is that I would like to have a project that is
reusable in other projects, which use SQL Server, Sybase, or MySQL.

The goal is to avoid duplicating code as much as possible. For example, I
would like to have one "Fill" method which works for any data provider.

Is this possible at all? Any link to articles/code?

Thanks
Mike

Re: Data Provider independent code by Cor

Cor
Thu Sep 09 06:45:31 CDT 2004

Mike,

That should be OleDB look at the connections strings for that.

http://www.connectionstrings.com/

Altough it is of course not independent from ADONET, because that is an
integrated part of dotNet.

(You loose with this approach of you of course performance when it is Oracle
or SQLserver)

I hope this helps?

Cor

> Hi,
>
> I would like to have a data layer that is independent from the data
provider
> and ADO.NET. What I mean is that I would like to have a project that is
> reusable in other projects, which use SQL Server, Sybase, or MySQL.
>
> The goal is to avoid duplicating code as much as possible. For example, I
> would like to have one "Fill" method which works for any data provider.
>
> Is this possible at all? Any link to articles/code?
>
> Thanks
> Mike
>
>



Re: Data Provider independent code by Joyjit

Joyjit
Thu Sep 09 07:03:39 CDT 2004

Hi,

what you really need is interface driven code, generic to any ADO.NET
provider. The following will help you
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndive/html/data010112001.asp

Regards
Joyjit

"Mike" <Mike@discussions.microsoft.com> wrote in message
news:9C00D0FC-37A0-49FB-91C4-844C0AFE2BF3@microsoft.com...
>
> Hi,
>
> I would like to have a data layer that is independent from the data
provider
> and ADO.NET. What I mean is that I would like to have a project that is
> reusable in other projects, which use SQL Server, Sybase, or MySQL.
>
> The goal is to avoid duplicating code as much as possible. For example, I
> would like to have one "Fill" method which works for any data provider.
>
> Is this possible at all? Any link to articles/code?
>
> Thanks
> Mike
>
>



Re: Data Provider independent code by Frans

Frans
Thu Sep 09 14:45:20 CDT 2004

Mike wrote:

>
> Hi,
>
> I would like to have a data layer that is independent from the data
> provider and ADO.NET. What I mean is that I would like to have a project
> that is reusable in other projects, which use SQL Server, Sybase, or MySQL.
>
> The goal is to avoid duplicating code as much as possible. For example, I
> would like to have one "Fill" method which works for any data provider.
>
> Is this possible at all? Any link to articles/code?

this only works if you abstract away your SQL actions as well. If you don't
your code is never going to be independent of which database to use.

You can come a long way with interfaces, however not all actions are
implemented on the ADO.NET interfaces. One being savepoints in transactions
for example.

Frans.

--
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

Re: Data Provider independent code by Paul

Paul
Fri Sep 10 08:27:36 CDT 2004

On Thu, 9 Sep 2004 04:05:02 -0700, "Mike" <Mike@discussions.microsoft.com> wrote:

¤
¤ Hi,
¤
¤ I would like to have a data layer that is independent from the data provider
¤ and ADO.NET. What I mean is that I would like to have a project that is
¤ reusable in other projects, which use SQL Server, Sybase, or MySQL.
¤
¤ The goal is to avoid duplicating code as much as possible. For example, I
¤ would like to have one "Fill" method which works for any data provider.
¤
¤ Is this possible at all? Any link to articles/code?

Unfortunately this probably isn't possible. The data access layer will have to be written to handle
different implementations amongst database products, such as the manipulation of BLOB data, data
type support, auto increment or sequencing, etc.

Your best bet would be to use stored procedures, which would be in line with what Frans is
suggesting, but the bottom line is that the data access layer will have to be database product
aware.


Paul ~~~ pclement@ameritech.net
Microsoft MVP (Visual Basic)