ODBC or ADO?? Advice needed

  • Thread starter Thread starter Me
  • Start date Start date
M

Me

I am writing a C#.NET application that is primarily intended to be used with
SQL server. One of my concerns is that in the future I will have users who
do not have or want to run SQL Server. That led me to think that perhaps I
should be using ODBC from the start.



What are your thoughts and suggestions on this? Will I still be able to run
stored procedures and use disconnected data sets if I use ODBC? Will there
be any loss of performance or other issues I should be aware of if I use
ODBC? Any other advice for me? Thank you.
 
What are your thoughts and suggestions on this? Will I still be able to run
stored procedures and use disconnected data sets if I use ODBC? Will there
be any loss of performance or other issues I should be aware of if I use
ODBC? Any other advice for me? Thank you.
Click to expand...

odbc is less performant and powerfull than ADO .NET.
what i would do in your case is use the free MSDE database engine.
basically this is a SQL server without the enterprise manager (and some
other differences)

because it is free, and compatible with SQL server itself, you would only
have to target 1
database type.

kind regards,
Bruno.
 
...
One of my concerns is that in the future
I will have users who
do not have or want to run SQL Server.
Click to expand...

The approach many advocates is to modularize your application into layers,
where you easily can exchange the datalayer from one dbms to another when
the need arises.

The best performance is almost always achieved when the database part of the
application is written especially for the target database at hand.

So you should encapsulate all queries and other calls to the database into a
separate module, which the rest of the application can use, without regards
on which database it's using. This module should have a coherent interface,
so when you exchange it for another module it's transparent to the rest of
the application.

Hence, a recommendation would be to define a separate interface for this
"database-proxy", which can be reused for the next one.
Will I still be able to run
stored procedures and use
disconnected data sets if
I use ODBC?
Click to expand...

Sure, but do the customers databases have the possibility to run stored
procedures?

That is another argument for writing the database-proxy. Even if your proxy
for SQL Server is based heavily on stored procedures, a proxy for e.g. MySQL
must have another approach, since it doesn't support stored procedures
(yet).
Will there be any loss of performance
Click to expand...

Absolutely, but in some cases ODBC could possibly be the only way to go,
when there is no other Data Providers available.

Hence, you maybe *should* write one database-proxy for ODBC *as well* as for
other dbms.

[Followup stripped down to only
microsoft.public.data.ado and
microsoft.public.data.odbc]

// Bjorn A
 
Back
Top