 |
|
| .NET DotNet Forum Index » ADO .NET Forum » Cannot display ODBC login prompt - want to connect... |
|
Page 2 of 2 Goto page Previous 1, 2 |
|
| Author |
Message |
| Scott M.... |
 Posted: Mon Sep 28, 2009 5:31 pm |
|
|
|
Guest
|
"John Brown" <JohnBrown at (no spam) discussions.microsoft.com> wrote in message
news:2B104035-0ADC-4BBC-8325-C8093F8E4801 at (no spam) microsoft.com...
Quote: Well, I didn't ask *part* of a question. I asked a whole question, and I
am
sure that you cannot deny that I asked it very clearly and concisely, so
if
he said "Yes", I can only assume that he must be have been responding to
the
whole question.
I can only assume he was respoding to *part* of the question because I'm
fairly confident that he does know that OleDb has no UI. So, if he knows
that, then his "yes" couldn't possibly be to answer both questions you
asked.
Just my take on it.
-Scott |
|
|
| Back to top |
|
|
|
| John Brown... |
| Posted: Mon Sep 28, 2009 6:38 pm |
|
|
|
Guest
|
"Scott M." wrote:
Quote:
"John Brown" <JohnBrown at (no spam) discussions.microsoft.com> wrote in message
news:2B104035-0ADC-4BBC-8325-C8093F8E4801 at (no spam) microsoft.com...
Not to flog a dead horse, but DSN-less connections existed in ODBC 1.0
(Sep.1992, according to Wikipedia.)
Well, I wasn't an ODBC expert, but I doubt the accuracy of that statement.
By it's very definition, ODBC required DSN's. The DSN's were the middle-man
created by the ODBC manager. The DSN was the extra layer that is precisely
the thing that causes the performance bottlenecks. It was OleDB that freed
us from ODBC and thus, DSN's. In other words ODBC = DSN.
-Scott
You can trust me on this. The function in the ODBC API that provides this
capability is SQLDriverConnect. According to the ODBC API reference, this
function was introduced in ODBC 1.0. The only doubt is when ODBC 1.0 was
released, but it was certainly long before OleDB. *1992* I got from
Wikipedia, but the rest is coming straight from the horse's mouth. See:
http://msdn.microsoft.com/en-us/library/ms715433(VS.85).aspx
If you are able to compile C programs, I would be happy to write a small C
program to demonstrate connecting without a DSN using the ODBC API, but that
would be Wednesday.
Regards,
John Brown. |
|
|
| Back to top |
|
|
|
| Scott M.... |
| Posted: Tue Sep 29, 2009 8:54 am |
|
|
|
Guest
|
Thanks for the offer, but I take your word for it. Question though: doesn't
that mean that the DSN-Less connection was available only to SQL databases?
And, for non-SQL users, you still needed a DSN?
-Scott
"John Brown" <JohnBrown at (no spam) discussions.microsoft.com> wrote in message
news:3295BC61-3C11-4454-A9DA-ABE932B7F297 at (no spam) microsoft.com...
Quote:
"Scott M." wrote:
"John Brown" <JohnBrown at (no spam) discussions.microsoft.com> wrote in message
news:2B104035-0ADC-4BBC-8325-C8093F8E4801 at (no spam) microsoft.com...
Not to flog a dead horse, but DSN-less connections existed in ODBC 1.0
(Sep.1992, according to Wikipedia.)
Well, I wasn't an ODBC expert, but I doubt the accuracy of that
statement.
By it's very definition, ODBC required DSN's. The DSN's were the
middle-man
created by the ODBC manager. The DSN was the extra layer that is
precisely
the thing that causes the performance bottlenecks. It was OleDB that
freed
us from ODBC and thus, DSN's. In other words ODBC = DSN.
-Scott
You can trust me on this. The function in the ODBC API that provides this
capability is SQLDriverConnect. According to the ODBC API reference, this
function was introduced in ODBC 1.0. The only doubt is when ODBC 1.0 was
released, but it was certainly long before OleDB. *1992* I got from
Wikipedia, but the rest is coming straight from the horse's mouth. See:
http://msdn.microsoft.com/en-us/library/ms715433(VS.85).aspx
If you are able to compile C programs, I would be happy to write a small
C
program to demonstrate connecting without a DSN using the ODBC API, but
that
would be Wednesday.
Regards,
John Brown. |
|
|
| Back to top |
|
|
|
| John Brown... |
| Posted: Tue Sep 29, 2009 1:18 pm |
|
|
|
Guest
|
"Scott M." wrote:
Quote: Thanks for the offer, but I take your word for it. Question though: doesn't
that mean that the DSN-Less connection was available only to SQL databases?
And, for non-SQL users, you still needed a DSN?
-Scott
No. Going back to my subject line, each ODBC driver contains a dialog that
allows you to configure it to make a connection. So all you have to do is
supply a minimum connection string, which can be a DSN or a driver name; a
totally empty connection string would not work.
/* incomplete code fragment */
char szOutConnectionString[256];
SQLSMALLINT lenReturnedString;
rc = SQLDriverConnect(hdbc, NULL, "Driver={Microsoft Access Driver
(*.mdb)}", SQL_NTS,
szOutConnectionString, 255,
&lenReturnedString, SQL_DRIVER_COMPLETE);
In this case, the MS Access driver will display a dialog box with all the
necessary and optional parameters that can be set when connecting to an
Access database. If you supply a connection string with all the required
keywords, the box will not appear at all. You will just connect. If the
string is incomplete, the dialog box will be filled in with whatever
information you supplied, and then you can fill in the rest, or change the
initial values.
I hard-coded the Access driver name, but I could have read a list of driver
names from the Registry. Whichever name I supply, I will get that driver's
login box. It does not matter whether it is Access, SQL Server, Oracle, or
CSV files. When the function returns, I will be connected and I will have the
*complete* connection string in szOutconnectionString.
Regards,
John Brown.
Quote: "John Brown" <JohnBrown at (no spam) discussions.microsoft.com> wrote in message
news:3295BC61-3C11-4454-A9DA-ABE932B7F297 at (no spam) microsoft.com...
"Scott M." wrote:
"John Brown" <JohnBrown at (no spam) discussions.microsoft.com> wrote in message
news:2B104035-0ADC-4BBC-8325-C8093F8E4801 at (no spam) microsoft.com...
Not to flog a dead horse, but DSN-less connections existed in ODBC 1.0
(Sep.1992, according to Wikipedia.)
Well, I wasn't an ODBC expert, but I doubt the accuracy of that
statement.
By it's very definition, ODBC required DSN's. The DSN's were the
middle-man
created by the ODBC manager. The DSN was the extra layer that is
precisely
the thing that causes the performance bottlenecks. It was OleDB that
freed
us from ODBC and thus, DSN's. In other words ODBC = DSN.
-Scott
You can trust me on this. The function in the ODBC API that provides this
capability is SQLDriverConnect. According to the ODBC API reference, this
function was introduced in ODBC 1.0. The only doubt is when ODBC 1.0 was
released, but it was certainly long before OleDB. *1992* I got from
Wikipedia, but the rest is coming straight from the horse's mouth. See:
http://msdn.microsoft.com/en-us/library/ms715433(VS.85).aspx
If you are able to compile C programs, I would be happy to write a small
C
program to demonstrate connecting without a DSN using the ODBC API, but
that
would be Wednesday.
Regards,
John Brown.
|
|
|
| Back to top |
|
|
|
| Scott M.... |
| Posted: Wed Sep 30, 2009 10:02 pm |
|
|
|
Guest
|
Quote: "Scott M." wrote:
I honestly believe that your design requirements (program doesn't know
anything about the data source, usesr supplies all pertinent connection
info., no custom UI need be developed) are unrealistic for any mainstream
application.
Excel is not a mainstream application? This is what I suggest: convince
Bill. When he tells the Excel team to take this feature out, I also won't
bother with it anymore.
Ah, but the feature, as you describe it, is not in Excel. When you tell
Excel to connect to a data source, it does exactly what I'm advocating and
not what you are suggesting.
It prompts for the type of data source, the log on credentials, and the
particular database data deired. It does not propmt for the connection
timeout, the buffer size, whether Multiple Active Result Sets should be
used, if the connection should be pooled, etc.
Excel does, in fact, need to know something about the available data sources
and how to connect to them. Well, to be more precise, the Windows component
that Excel uses to provide connectivity to various data sources does need to
know certain aspects of how to connect to those resources and it does not
ask the user to supply those data. Also, depending on the data source you
do select as a data source to connect to in Excel, you will get a different
dialog to complete, which makes my point that someone over there at MS had
to program various custom dialogs depending on the data source selected.
In effect, when MS created the connect to data source feature for Excel,
they followed the exact design pattern I've suggested for you:
1. The program does know something about the various types of data sources
you can connect to.
2. The program does put up custom dialogs, based on the data source chosen.
3. The user is not required to supply any connection configuration
parameters beyond:
a. The type of data source to connect to.
b. Windows vs. custom authentication with the user's credentials
c. The specific database/table to connect to.
-Scott |
|
|
| Back to top |
|
|
|
| John Brown... |
| Posted: Thu Oct 01, 2009 10:18 am |
|
|
|
Guest
|
"Scott M." wrote:
Quote: I think the big point you've glossed over is that, while Excel *can* show
you extended connection properties, you don't *have* to see them.
Quote: They are
not provided up front for the user to look at and guess which ones they are
supposed to fill in. This is the key point and the reason that I say that
Excel is more of an example of how I suggest you build a DB program and less
of an example of how you have indicated you'd like to go.
-Scott
True, this is a refinement that my crude PropertyGrid dialog lacks.
Of course, when SuperDB is released, my users may have to guess (or read the
SuperDB manual as they should), unless the OLEDB and/or ADO.NET specs say
that each property must indicate whether it is absolutely required. They
probably do, because I do not and never will believe that Excel contains a
gigantic select case statement with a branch for every OLEDB provider that
has ever been written.
And don't forget about the ones that have not been written. What do you
think Excel 2007 is likely to do when it is confronted with SuperDB 2012?
Regards,
John Brown.
Regards,
John Brown. |
|
|
| Back to top |
|
|
|
| Scott M.... |
| Posted: Thu Oct 01, 2009 11:09 am |
|
|
|
Guest
|
"John Brown" <JohnBrown at (no spam) discussions.microsoft.com> wrote in message
news:C54C8347-C979-4CED-837C-60E467AC9B4A at (no spam) microsoft.com...
Quote: And don't forget about the ones that have not been written. What do you
think Excel 2007 is likely to do when it is confronted with SuperDB 2012?
Well, that's exactly my point. The current programming of Excel (or more
accuartely the Windows Data Source Connection component) would prohibit
connections to SuperDB if it could not be connected to using a current
provider/driver. An updated version of the program would have to be written
and released giving Excel those capabilities. This happens all the time
with the Microsoft Data Access Component librry (MDAC). New providers and
drivers are added so that existing software will know how to connect and
communicate with them. But, the software itself is not written in such a
way that it can handle any new data source that comes down the line (SuperDB
2012).
-Scott |
|
|
| Back to top |
|
|
|
| John Brown... |
| Posted: Thu Oct 01, 2009 12:11 pm |
|
|
|
Guest
|
"Scott M." wrote:
Quote:
"John Brown" <JohnBrown at (no spam) discussions.microsoft.com> wrote in message
news:C54C8347-C979-4CED-837C-60E467AC9B4A at (no spam) microsoft.com...
And don't forget about the ones that have not been written. What do you
think Excel 2007 is likely to do when it is confronted with SuperDB 2012?
Well, that's exactly my point. The current programming of Excel (or more
accuartely the Windows Data Source Connection component) would prohibit
connections to SuperDB if it could not be connected to using a current
provider/driver. An updated version of the program would have to be written
and released giving Excel those capabilities. This happens all the time
with the Microsoft Data Access Component librry (MDAC). New providers and
drivers are added so that existing software will know how to connect and
communicate with them. But, the software itself is not written in such a
way that it can handle any new data source that comes down the line (SuperDB
2012).
-Scott
I find that very hard to believe, but since SuperDB isn't out yet, I'll
leave there.
Regards,
John Brown. |
|
|
| Back to top |
|
|
|
|
|
All times are GMT - 5 Hours
The time now is Fri Nov 27, 2009 11:18 pm
|
|