Re: Cannot display ODBC login prompt - want to connect without DSN

Please forget the .NET evangelism for a minute and concentrate on what I
am
saying. Very early in the piece, I posted ADO code that could connect to
any
database without knowing anything beforehand except the driver name. If
you
have a generic API that will handle specific objects of different types,
it
is wise to have ways of querying the objects to find out their
capabilities,
ways to tell them to configure themselves, etc.

What you are telling me is that if I am writing a word processor and my
app
wants to print, it should display a standard print dialog box, and if my
users want to use some printer-specific feature that I didn't think of,
then
too bad. Fortunately it doesn't worklike that. The printer driver knows
how
to configure the printer, so neither my app nor GDI needs to know what the
printer is capable of. However, ny GDI code to print would be exactly the
same, regardless of the printer. I do not consider this to be a bogus
concept.

There's no evangelism going on here. I think you are presuming that ADO
..NET and OleDb must somehow work just as ADO and ODBC did, which they do
not. It's actually very simple, in order to connect to any data source, you
need a connection string and different data sources use different connection
strings. You are telling me that you'll need to connect to Access and
Oracle, so that means you need to have two different connection strings.
The best practice is to store connection strings in your app.config or
web.config file, so you'd need to set up the basic shell for both of theses
and fill in the missing pieces later. This isn't a big deal and I'm not
sure why you seem so hung up on it. You'll just have two connection strings
standing by and a simple "if" statement to determine which is necessary at
runtime.

There's nothing about this that is evangelistic or even an opinion. This is
how connections are made in ADO .NET with OleDb - - you need to forget about
ODBC, ADO, and VB Script. They are gone (and a long time ago).

Now I understand. You are assuming that connecting to a database is just a
matter of supplying credentials. (By the way, you left out server). Even
supplying credentials can be tricky. Consider SQL Server, but remember
that
my app has no built-in knowledge of SQL Server. I present a list box with
the
names of all OleDB providers on your computer. You select the one for SQL
Server. I display my generic box to get your user name, password, database
and server. I Build my ConnectionString: Provider=whatever;Data
Source=User
Id=johnbrown;Password=password;I

First, I reject the scenario you have started out with. All you need from
the end user is their id, password, and database. You would not present
them with a list of OleDb Providers because they wouldn't understand what
that list represents. Since you've stated that you might need Access or
Oracle, you could just provide them with a radiobutton set with those two
choices.


Problem: Your environment uses Windows Authentication.

This is less a programming issue and more of a configuration issue. But, if
you need windows authentication, you can certainly set up the connection
string to use it.


Problem: Even if you leave the fields blank, you still cannot connect,
because I need to specify the keyword to turn on Windows authentication.

Problem: the program doesn't know that.


This is where I am bit confused. Are you saying that the user gets to tell
your program if Windows Authentication is being used? This is not something
that end users know and understand and hardly something that you'd ask them
to tell you. You should know how your users need to connect and code for
that.

There are more problems, such as:

Problem: How do I specify the database? Sometimes, the keyword is
"Initial
Catalog", sometimes it is "Database"; there may be others. There are
endless
keywords. Some are necessary, some are optional. For example, maybe system
tables are hidden by default (SQL Anywhere), but now I need to see them.
How
would I know how to make system tables visible?

Solution, the SqlConnectionStringBuilder class. This is not the problem you
think it is.


You can connect to all sorts of databases, and things that are not really
databases, such as a SharePoint site, an MS Exchange Server, etc. A
generic
dialog box will not work for all data sources.

Your OP was that you need to code against Access or Oracle, now you are
saying it could be anything?


My users, who may not even know what an OleDB connection string is, are
now
supposed to look in the programmer's documentation for their database,
where
they might never think of looking because they are not programmers, so
that
they can use my fantastic reporting tool?

Your users don't need to even hear the words "connection string" or
"OleDb",
but yes, shouldn't they know where their own data is and their own
credentials to access it?


It's not all about credentials. See above.

It really is. There's a picture that I have obviously not been able to
convey to you, but you only need 3 pieces of info. from your users and it
need not be technical:

What is the Database/Data Source you want to connect to (a simple dropdown
list can handle this - no need to talk about providers).
What is your User Name?
What is your ID?

Based on the answer to question #1, your program uses the correct connection
string and fills in the gaps with #'s 2 and 3.




That does not look like progress to me, but maybe the DBProvider
business
above solves the problem.

The DBProvider Factory will only help you code one pattern that can work
for
the two different databases, it's not going to help you figure out your
connection strings. Honestly, (and I may be missing something here),

Yes, you certainly are, but I hope that my latest explanation clears
things
up.


but I
am a bit dumbfounded that you have resistence to the idea that a user
would
need to supply credentials to access a secured resource.

I have not the slightest idea what you are talking about. I am resisting
the
idea that with backward, "dead" technology, I could write a program to
connect to a database and execute a few inserts and selects without
knowing
or caring (much) about the database,in the same way that a program can
print
regardless of the printer, or send emails without knowing which email
program
is installed. Now I have to care, because I can't connect unless I specify
a
correct connection string.

But, with ODBC you couldn't connect without using the proper DSN. We're
simply replacing your code's selection of a DSN with your code's selection
of a connection string. Just like your ODBC programs supplied a way for the
user to tell you who they are, your OleDb programs would do the same.



You seemed to be
ok with the ODBC login dialog popping up to promt the user to fill in the
details, why are you having trouble with having them do the exact same
thing, but with a dialog that you create?

It's not all about credentials. You are telling me that if I want to write
an app that will work with any database (let's say any database that has a
certain minimum capability), then I would have to write a login dialog box
for each one. This is not practical. Anyway, I have not investigated
DBProvider yet.

What I am having trouble understanding is that it seems that you want the
user to tell the program (or you think that I'm saying that a user should
tell the program) explicit details about how to connect to the desired data
source. I'm not saying that, but it seems that you are and I don't
understand why.

-Scott





<snip>

If I call OleDBConnection::Open with an incomplete ConnectionString
(just
the provider name) can I make the provider display a login dialog
box?

Again, no. the login box which you are talking about was provided to
ODBC
by
the Windows Operating System via the ODBC Managaer. Taking ODBC out
of
the
picture (which you should) means that the dialogs are gone too.


From the description of SQLDriverConnect in the ODBC API reference at
http://msdn.microsoft.com/en-us/library/ms715433%28VS.85%29.aspx

"Based on the value of DriverCompletion, the driver prompts the user
for
connection information, such as the user ID and password, and connects
to
the
data source:

SQL_DRIVER_PROMPT: *** The driver displays a dialog box ***,
============================
using the values from the connection string and system information (if
any)
as initial values. When the user exits the dialog box, the driver
connects
to
the data source. It also constructs a connection string from the value
of
the
DSN or DRIVER keyword in *InConnectionString and the information
returned
from the dialog box. It places this connection string in the
*OutConnectionString buffer."

Even without this documentation, it is obvious that each ODBC driver
*must*
export a function to do this so that the ODBC Driver Manager can call
it
when
required. Otherwise the Driver Manager would have to magically know all
the
required and optional values that can be used to make a connection for
maybe
dozens or hundreds of drivers, and then construct a dialog box at run
time,
complete with tabs, checkboxes and what not.

I'm not sure what your point is here. OleDb is NOT ODBC. Comparing the
two
architectures for similarities is futile.

I am saying that the ability to connect to a database without knowing the
details is not magic; it was provided by each ODBC driver. If OleDB
providers
do not have this capability, then it is a backward step.

Regards,
John Brown.


.

Loading