Is ODBC useless, or OK in some circumstances?

[lastusernameleft]

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]

On Thu, 25 Aug 2005 08:04:05 -0700, "lastusernameleft" <la**************@discussions.microsoft.com>
wrote:

¤ 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)

[lastusernameleft]

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.

"Paul Clement" wrote:

On Thu, 25 Aug 2005 08:04:05 -0700, "lastusernameleft" <la**************@discussions.microsoft.com>
wrote:

¤ 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)

[steve]

Sounds like a really handy application. Companies pay big bucks for
monitoring software that essentailly does the same thing with event
alerts. I also don't see why they would scrap your app until they have
something to replace it with.

I'm not sure what user authentication/authorization ODBC is providing
you other then storing a user/pass in the DSN. My point is that it's
only a few lines of code to grab a user/pass from the registry or some
other location and then your .net data provider would give you the same
functinoality as your ODBC DSN.

Regarding database roles, best practices suggest if you need to give
users different levels of access you should build application roles
rather then using database roles for several reasons. For example,
performance and scalability greatly suffers when you log every user
into the database with a seperate user acount. However, implementing
application roles requires coding and can be tricky, but essential to
writting enterprise grade apps. Just my 2 cents.

Steve.

[lastusernameleft]

Thanks for the feedback.

Actually my app doesn't have event alerts, it just allows the browsing of
System Event Logs, Security Logs, and Application logs on remote machines,
displays the AD memberships of the user, user/machine info, installed
software, etc. and lets an admin interact with the machines, nothing they
can't already do, just convenient in one place. And unfortunately I don't
have the ability to change rights from database roles since I am linking in
to existing enterprise database solutions, CRM and asset tracking systems,
the final polished product may alter acess behavior, but not me on my own.

Perhaps I'm overestimating the degree of difficulty in implementing
authentication, but you mentioned getting values from the registry, which
doesn't seem secure to me, and as I don't have admin access to the servers I
am linking to (I made this thing entirely on my own) I can't get any user
rights info from there as well, so I'm still at a loss as to how I would
synch the app credentials with the servers.

I hope this makes sense, I'm new to Windows Integrated Authentication,
finding my way around.
thanks


"steve" wrote:

Sounds like a really handy application. Companies pay big bucks for
monitoring software that essentailly does the same thing with event
alerts. I also don't see why they would scrap your app until they have
something to replace it with.

I'm not sure what user authentication/authorization ODBC is providing
you other then storing a user/pass in the DSN. My point is that it's
only a few lines of code to grab a user/pass from the registry or some
other location and then your .net data provider would give you the same
functinoality as your ODBC DSN.

Regarding database roles, best practices suggest if you need to give
users different levels of access you should build application roles
rather then using database roles for several reasons. For example,
performance and scalability greatly suffers when you log every user
into the database with a seperate user acount. However, implementing
application roles requires coding and can be tricky, but essential to
writting enterprise grade apps. Just my 2 cents.

Steve.