Using any Data Provider

[Dino Buljubasic]

Hi,

How do I write a db driven app that will work independently of data
provider. No matter whether backend is Oracle, SQL Server, mySQL or
Access, it should work smoothlesly

tx

 

[S.M. Altaf [MVP]]

Sounds like you're a good candidate to use the Data Access Application
Blocks (DAAB) from MS Best Practices.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/daab.asp

HTH
-Altaf [MVP-VB]

 

[Sahil Malik [MVP]]

You can use something similar to the DBProviderFactory model in .NET 2.0.

Do realize however that when writing code for specific data sources, there
will be lot of code that you will have to write for each database
seperately. In other words, a TSQL stored proc, will never be the same as a
PLSQL stored proc etc.

In short the epitome of the database independent data layer - is impossible.
But you should seperate that junk out in a layer as thin as possible.

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx

 

[The Crow]

u are wrong. if you design your data access layer clever enough, its
possible..

its nearly possible to implement all T-Sql stored procedures in pl-sql just
with a few tricks and/or syntax. but oracle has ref cursor output parameter
you have to use when you use datareader. if your ExecuteReader methods in
your dataacess layer cleverly adds that parameter to executing commands
parameter collection, it should run in the same manner. all you have to do
rest is rewriting stored procedures in pl-sql. (if you use any)

 

[Cor Ligthert [MVP]]

Dino,

I added an answer in the ADONET newsgroup on your same message about this.
(As more did that today)

Cor

 

[David Farr]

I'm using an Interface to do this, by creating components for each database
type and instantiating the required type at runtime.

Check out the excellent example by WillemM:-
http://www.codeproject.com/cs/database/Pluggable_Data_Access.asp

Rgds,
Dave

 

[Sahil Malik [MVP]]

The Crow,

All TSQL procedures can be implemented in PLSQL - afterall equivalent logic
concepts do exist on either side.

However, since the two databases are inherently different, the function
names are different, concurrency mechanisms are different, and a number of
other differences, it will rarely be as simple as the example you pick.
Trust me, it is not as simple as "cleverly adding a parameter".

For selects it may even work, the real problem occurs when you try saving
data back into the database.

 

[Sahil Malik [MVP]]

I beleive your answer was to use OleDb or ODBC.

Yes that may work, but you get a much restricted feature set, and a much
lower performance.


--

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx

 

[Cor Ligthert [MVP]]

OleDb,

Yes that may work, but you get a much restricted feature set, and a much
lower performance.

As I wrote.

Cor