I thinking that I want to write a class which handles all database access
hiding from the calling program what type of database which is being
accessed and all of the database specific things.

I would include methods to bind the dataset/datareader to the control,
returning a datatable and the dataset if necessary.

All updates would be done through methods, etc.

One of the problems that I can see which is somewhat of a challenge to deal
with are stored procedure parameters. There is some commonality of the
datatypes across the various databases (OleDB, SQL, Oracle), but there is
not uniformity. I was thinking that I would use the generic DbType and
have the calling program pass this data type and then translate it to the
appropriate type of the database which is actually being accessed, but this
would not handle all situations.

Any idea how I can overcome this?

Is there a better design approach?

Re: Database Access Base Class by John

John
Thu Dec 18 13:12:38 CST 2003

Take a look at this link:

http://www.c-sharpcorner.com/Code/2002/July/GenericDataAccessCompActivator.asp

Good Luck

"Jim Heavey" <JimHeavey@nospam.com> wrote in message
news:Xns94556DA8C7D2FJimHeaveyhotmailcom@207.46.248.16...
> I thinking that I want to write a class which handles all database access
> hiding from the calling program what type of database which is being
> accessed and all of the database specific things.
>
> I would include methods to bind the dataset/datareader to the control,
> returning a datatable and the dataset if necessary.
>
> All updates would be done through methods, etc.
>
> One of the problems that I can see which is somewhat of a challenge to
deal
> with are stored procedure parameters. There is some commonality of the
> datatypes across the various databases (OleDB, SQL, Oracle), but there is
> not uniformity. I was thinking that I would use the generic DbType and
> have the calling program pass this data type and then translate it to the
> appropriate type of the database which is actually being accessed, but
this
> would not handle all situations.
>
> Any idea how I can overcome this?
>
> Is there a better design approach?