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


"John Brown" <JohnBrown@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:C5F5D28B-2A07-45F7-996A-FC7F998BE430@xxxxxxxxxxxxxxxx


"Scott M." wrote:


"John Brown" <JohnBrown@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:937278FB-2561-43F4-BB09-57D6C3FEF0B2@xxxxxxxxxxxxxxxx


"Scott M." wrote:


Depending on the database you are using, you'll need a specific
provider
with a specific connection string to match it.

This is what I am trying to avoid. I want to write *one* program that
will
work with *two* databases (MS Access and Oracle) with *no* code changes
whatsoever.

Well, think about what you just said. There will objviously have to be
code
set up to accomodate the two possible database types,

Not necessarily. My app is not going to create the database or the tables.
It simply loads an XML files into two tables with no columns with exotic
data
types. There is exactly *one* Access-specific SQL statement in there, but
I
am going to get rid of it.

Yes necessarially. If you are going to possibly deal with two different
databases (regardless of what you intend to do with those databases), your
application must be prepared to connect to the two different databases.
There's no getting around that.


but there's no reason
you can use the DBProvider factory classes to accomodate either database
being used.

http://www.davidhayden.com/blog/dave/archive/2007/10/08/CreatingDataAccessLayerUsingDbProviderFactoriesDbProviderFactory.aspx


I have not read this thoroughly yet. It looks promising, even though it
seems that it still relies on pre-existing knowledge of the full
connection
string.

Well, you need to know the basics of the connection string and can populate
the unknowns at runtime with data from the client. If you want to connect
to Access, you must know how to do that. If you want to connect to Oracle,
you must know how to do that as well. But, we're just talking about the
connection string here. The beauty of the ADO .NET objects is that once
you've made your connection, you use the objects the same way.

I may be wrong, but I'm getting the impression that you belive you can (or
should be able to) code a database application that *may* need to connect to
one of two database types without knowing how to code or having to code that
functionality.




<snip>

There are no "login boxes" for OleDB. As I said, if you want a user to
supply their credentials, you can create your own login form for them to
supply the information to you and you can inject those credentials into
the
connection string.


So you're saying that if I wanted to write a report writing tool using
OleDB, which is supposed to work with just about any database that exists
now
or may be developed in the future, I would have to display a dialog box
asking for the usual suspects (user name, password, database, server) and
another text box for extra connection parameters, because I hav no way to
discover them at run time.

Well, if you don't know the details of the connections you need to make at
design-time, then when else would you get them but run-time? And if you
don't have the information and only the end user does, then who else can you
ask to supply the detials? You should only need to ask them for their user
name, password, and database.


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?


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), 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. 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?


<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.

-Scott




.

Relevant Pages

  • Re: Ad connection to HR Database
    ... Hilltop Lab - http://www.rlmueller.net ... The connection string ... the server name, instance name, and database name. ... to know what your opinion was about odbc connection or linking the ...
    (microsoft.public.windows.server.scripting)
  • Re: DSN-less connection for Informix database
    ... build an odbc for using the specificed driver ... ... Pervasive ODBC client Interface ... ... having to SETUP an odbc connection profile .. ... in your connection string, replace the DNS=jaco ... ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Clipper and ADO
    ... It'll be the ODBC driver. ... Look for the ODBC Admin icon in control panel. ... directory specified in the connection string but the above MS link should ...
    (microsoft.public.vb.general.discussion)
  • Re: odbc settings
    ... incorrect in that it's not actually pointing to a SQL Server database. ... "Can not find a installable ISAM" I put the connection string code in the ... I have an odbc setup on my box and the connection works great. ...
    (microsoft.public.sqlserver.odbc)
  • Re: DSN-less connection for Informix database
    ... Is there a way to find out the ODBC driver version on the client ... on is having to SETUP an odbc connection profile .. ... in your connection string, replace the DNS=jaco ... ...
    (microsoft.public.dotnet.languages.vb)
Loading