2) More generally, is there an equivalent to the
ADODB.Connection::Properties collection in ADO.Net?

"John Brown" <JohnBrown at (no spam) discussions.microsoft.com> wrote in message
news:5F054111-768C-4FD8-86FF-468FB02F9312 at (no spam) microsoft.com...

2) More generally, is there an equivalent to the
ADODB.Connection::Properties collection in ADO.Net?

More pertinently, why on earth are you using ODBC...?


--
Mark Rae
ASP.NET MVP
http://www.markrae.net

"Mark Rae [MVP]" wrote:

"John Brown" <JohnBrown at (no spam) discussions.microsoft.com> wrote in message
news:5F054111-768C-4FD8-86FF-468FB02F9312 at (no spam) microsoft.com...

2) More generally, is there an equivalent to the
ADODB.Connection::Properties collection in ADO.Net?

More pertinently, why on earth are you using ODBC...?


--
Mark Rae
ASP.NET MVP
http://www.markrae.net


And what, pray tell, should I be using?

I knew about OleDB. Wasn't ADO built open OleDB as a way of shielding VB
programmers from the complexity of OleDB?

The real reason I have been ODBC with ADO is that I am lazy. I cannot
remember
the names of the providers in which I am interested. I have to look them
up each time.

In this particular case, my program will conect to an Oracle database, but
I
don't have Oracle here. I'm too lazy to make a trip just so that I can run
my
program (to convert an XML file into records in a table) against an Oracle
database.

There does not seem to be a .NET provider for [MS Access] Jet,

and even if there were, I would have to write different code depending on
the database
that I was connecting to:

You haven't answered the original question. Can you try this one instead:

If I use the ADO.Net provider for OleDB, and I allow the user to select an
OleDB provider from a list of providers installed on his PC , will I be
able
to display that provider's login box and let the user connect, and then
save
the resulting ConnectionString to be re-used in the future?

Your point is well taken, but as I said earlier, my app needs to work with
2
databases.

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

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

Even though I know exactly which databases my progam is expected
to work with, so I don't have to support an arbitrary unknown database, I
still want to be able to use the program with a database other than Access
or
Oracle. If the OleDB provider has its own login dialog box, I would rather
display that one than make my own form to do the same thing.

With ODBC, this is quite simple. I can present a list of installed ODBC
drivers. When the user selects one, I just need to:

'VBScript
Dim cnn
Set cnn = CreateObject("ADODB.Connection")
cnn.ConnectionString = "Driver={" selectedDriver & "}"
cnn.Properties("Prompt") = 2
cnn.Open

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

"John Brown" <JohnBrown at (no spam) discussions.microsoft.com> wrote in message
news:937278FB-2561-43F4-BB09-57D6C3FEF0B2 at (no spam) microsoft.com...


"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, 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


Even though I know exactly which databases my progam is expected
to work with, so I don't have to support an arbitrary unknown database, I
still want to be able to use the program with a database other than
Access or
Oracle. If the OleDB provider has its own login dialog box, I would
rather
display that one than make my own form to do the same thing.

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.


With ODBC, this is quite simple. I can present a list of installed ODBC
drivers. When the user selects one, I just need to:

'VBScript
Dim cnn
Set cnn = CreateObject("ADODB.Connection")
cnn.ConnectionString = "Driver={" selectedDriver & "}"
cnn.Properties("Prompt") = 2
cnn.Open

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.

-Scott

Forget ODBC, it's archaic and doesn't
perform nearly as well as OleDb.

Good luck!

Forget ODBC, it's archaic and doesn't
perform nearly as well as OleDb.

Why do you think that they have released a new ODBC version (3. for
Windows 7?

"John Brown" <JohnBrown at (no spam) discussions.microsoft.com> wrote in message
news:D1045989-6EFE-43B0-A0D0-1914205C7960 at (no spam) microsoft.com...

Forget ODBC, it's archaic and doesn't
perform nearly as well as OleDb.

Why do you think that they have released a new ODBC version (3. for
Windows 7?

For databases which have neither a native .NET data provider nor an OleDb
provider.

snip

"Scott M." wrote:

snip
Forget ODBC, it's archaic and doesn't
perform nearly as well as OleDb.

Good luck!


Why do you think that they have released a new ODBC version (3. for
Windows 7?

Regards,
John Brown.

After a multitude of posts with much information that is completely
irrelevant to my simple and clearly-stated problem, we're finally getting
somewhere. I have not gone through it yet, but it seems to be a more
complicated and less general technique than the DBProvider class mentioned
by
the other poster.

You haven't answered the original question. Can you try this one
instead:

If I use the ADO.Net provider for OleDB, and I allow the user to select
an
OleDB provider from a list of providers installed on his PC , will I be
able
to display that provider's login box and let the user connect, and then
save
the resulting ConnectionString to be re-used in the future?

Yes.


The other poster who has replied says that you can't. In particular, he
says
that OleDB providers do not have their own login dialog box so I must
supply
my own. Of course, I would rather agree with you.

Your point is well taken, but as I said earlier, my app needs to work
with
2
databases.

See above...
My DAL works with SQL Server, SqlCe, Oracle, MySql and Jet (which some
people incorrectly refer to as Access), and can be dropped *completely*
unmodified into any WinForms or WebForms project. If I ever need to
support
another RDBMS, it would be a simple matter of adding it to the factory
pattern.

So you support several databases with the same code, but to add another,
you
would have to make a small change. This will work for me, but it is not
the
same as my program being able to connect to an arbitrary database without
my
knowledge or permission.

snip

This is exactly what I've been recommending to you all along. The "factory"
pattern is the same thing as the DBProvider solution I've been suggesting.

You haven't answered the original question. Can you try this one
instead:

If I use the ADO.Net provider for OleDB, and I allow the user to select
an
OleDB provider from a list of providers installed on his PC , will I be
able
to display that provider's login box and let the user connect, and then
save
the resulting ConnectionString to be re-used in the future?

Yes.


The other poster who has replied says that you can't. In particular, he
says
that OleDB providers do not have their own login dialog box so I must
supply
my own. Of course, I would rather agree with you.

As I stated, OleDb does not supply ANY form of UI. What I belive Mark was
saying "yes" to was the "could I save the connection string for later use"
part, which you can.

John, I really am trying to help you out here, but I've got to say that you
seem to be shooting down suggested courses of action, without really having
any knowledge or experience with what's being suggested.

... you can get just what you want with
the DB Factory paradigm (implemented via the DBProvider classes) and two
basic connection strings that are completed with user imput using the
ConnectionStringBuilder class.

Please take the time to research these items (links previously provided) and
you'll see that it's what you want.

It may not have the built in login
boxes that you used to have, but the performance gains as well as the device
indepenence is well worth doing DSN-less connections, which were introduced
13 years ago.

Not to flog a dead horse, but DSN-less connections existed in ODBC 1.0
(Sep.1992, according to Wikipedia.)