Dinko:
SqlClient is optimized for SqlServer. To say that OleDb is optimized for
all other databases though is a bit of a stretch. I'd recommend using a
factory pattern to build your logic with. You can easily branch it to
another provider with minimal changes but it's important to remember that
there are some pretty notable differences in Database implementations. If
you upgrade from Access to SQL Server, you'd have a little rework, but what
if you went to Oracle? If you used OleDb originally, you'd still be in a
situation where you were using a non-native provider or you'd have the
rework to do to migrate to a new provider.
A factory will allow you to specify what's what and create objects
accordingly, but taking advantage of any provider specific db is
antagonsitic to any truly 'generic' approach. Access doesn't use stored
procs the same way sql server does and it has different datatypes.
Which leads to another point. Even if you did use OleDb, you'd still
probably have to port your code to SqlServer or Oracle if you changed b/c
ISNULL is totally different in Access than it is in Oracle or T-Sql. Dates
are handled differently. There are many other subtleties that could effect
the occassion as well.
Changing back ends is something that probably won't happen but once, twice
at the most in any case I've worked with...and twice was a LOT.
So a pretty simple factory pattern could handle this for you, and then
when/if you migrate to SqlServer, you could get it ported then start taking
advantage of the procs, UDF's etc and migrate at a comfortable pace.
HTH,
Bill
These might also help..
http://abstractadonet.sourceforge.net/
http://www.dnzone.com/showDetail.asp?TypeId=2&NewsId=276