Is ODBC useless, or OK in some circumstances?

[Guest]

For an application displaying read only data targeting a small audience it
would seem to me that using ODBC DSNs to delegate user authentication would
be quicker to develop than recreating that same authentication and
authorization within the app using dotnet data providers, though of course
ODBC is outdated and would be a deployment headache and would limit
scalability. But in certain cases, could it be considered professionally
acceptable to use ODBC these days in the .NET world?

 

[steve]

Sometimes you have to use ODBC if there is no other choice. However,
if you can use a native data provider or at least oledb I personally
would consider ODBC not acceptable. Just a bit more code to handle
user authentication and you can avoid the obvious ODBC DSN headaches
and limitations.

 

[Paul Clement]

¤ For an application displaying read only data targeting a small audience it
¤ would seem to me that using ODBC DSNs to delegate user authentication would
¤ be quicker to develop than recreating that same authentication and
¤ authorization within the app using dotnet data providers, though of course
¤ ODBC is outdated and would be a deployment headache and would limit
¤ scalability. But in certain cases, could it be considered professionally
¤ acceptable to use ODBC these days in the .NET world?
¤

I would agree with Steve's response. If you can use a more up-to-date data provider, such as OLEDB
or native .NET (assuming they're stable), I wouldn't use ODBC.


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[Guest]

I am in total agreement, except for the amount of time and effort it would
take to create proprietary database authentication/authorization within the
application. Maybe I'm missing something, but how would Windows Integrated
Authentication access database specific roles on different servers?

I made a small .NET app integrating various data sources, Oracle, SQL, Lotus
Notes, plus Active Directory, Event Logs, etc, into a singleview interface,
my purpose being quick turnaround (it was ready in 3 weeks), for a limited
audience (LAN admins and technicians), never intended to be scalable, just a
simple automation of common tasks, using readily available solutions (ODBC,
behind the scenes batch files and vb scripts, etc)

Now its very popular and the company I work for (a large one) wants to
architect the whole thing from the ground up, with new features, etc, which I
of course agree with. But they are considering entirely scrapping this
initial clunky version until the final product is ready, months away. This
current version is fast and stable, and most importantly gets the job done,
so my argument is that it is ok to live with a mish mash of new and old for a
limited time, till the new is ready, though some seem to think its entirely
unacceptable. Thanks for the feedback.