Hello!
I was wondering if I need to install something on the client in order to
establish ODBC/OLEDB connection to SQL Server 2005. Currently, I have ADO
2.6 installed. Are there any changes in ODBC/OLEDB drivers for SQL Server
2005?
Thanks,
IgorHi
It is best to use MDAC 2.8, but 2.6 will connect to SQL Server 2005, but you
will not be able to use the new datatypes that SQL Server 2005 has
introduced.
The ODBC/OLEDB drivers no longer ship with SQL Server, as it is now a
function of the Operating System to update them.
The new way to connect to SQL Server 2005 is SQL Native Client (SQLNCLI)
"Provider=SQLNCLI"
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"imarchenko" <igormarchenko@.hotmail.com> wrote in message
news:ulvm%23pcCGHA.2300@.TK2MSFTNGP15.phx.gbl...
> Hello!
> I was wondering if I need to install something on the client in order
> to establish ODBC/OLEDB connection to SQL Server 2005. Currently, I have
> ADO 2.6 installed. Are there any changes in ODBC/OLEDB drivers for SQL
> Server 2005?
> Thanks,
> Igor
>|||"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:%2326c1IiCGHA.3984@.TK2MSFTNGP14.phx.gbl...
> Hi
> It is best to use MDAC 2.8, but 2.6 will connect to SQL Server 2005, but
> you will not be able to use the new datatypes that SQL Server 2005 has
> introduced.
> The ODBC/OLEDB drivers no longer ship with SQL Server, as it is now a
> function of the Operating System to update them.
> The new way to connect to SQL Server 2005 is SQL Native Client (SQLNCLI)
> "Provider=SQLNCLI"
>
This is not quite right. MDAC is part of the operating system, but SQL
Native Client is not.
The SQL Native Client is a seperate install. It is included in the SQL
Server distribution and available here:
http://msdn.microsoft.com/data/sqlnative/default.aspx
There are now 3! OleDb providers for SQL Server. Two in MDAC: MSDASQL
(deprecated) and SQLOLEDB (current). Plus one in the SQL Native Client
(SQLNCLI). SQLNCLI is the best, but you must install it.
SQL Native Client also has a new ODBC driver.
David|||David,
I am able to connect to SQL Server 2005 using SQL Native Client but
I got en error 'Server unavailable or access denied ...' when trying to
connect using Microsoft OLE DB provider for SQL Server. I am trying to
connect by setting up properties of UDL file on the same box where SQL
Server is installed. Did I get it right that I have to install latest
drivers on client computers from the link your provided?
Thanks,
Igor
"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
message news:O$2MO8jCGHA.2664@.TK2MSFTNGP15.phx.gbl...
> "Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
> news:%2326c1IiCGHA.3984@.TK2MSFTNGP14.phx.gbl...
> This is not quite right. MDAC is part of the operating system, but SQL
> Native Client is not.
>
> The SQL Native Client is a seperate install. It is included in the SQL
> Server distribution and available here:
> http://msdn.microsoft.com/data/sqlnative/default.aspx
> There are now 3! OleDb providers for SQL Server. Two in MDAC: MSDASQL
> (deprecated) and SQLOLEDB (current). Plus one in the SQL Native Client
> (SQLNCLI). SQLNCLI is the best, but you must install it.
> SQL Native Client also has a new ODBC driver.
> David
>|||David,
I wa able to connect by enabling remote connections using Surface Area.
Thanks,
Igor
"imarchenko" <igormarchenko@.hotmail.com> wrote in message
news:%23t2FLdxCGHA.724@.TK2MSFTNGP10.phx.gbl...
> David,
> I am able to connect to SQL Server 2005 using SQL Native Client but
> I got en error 'Server unavailable or access denied ...' when trying to
> connect using Microsoft OLE DB provider for SQL Server. I am trying to
> connect by setting up properties of UDL file on the same box where SQL
> Server is installed. Did I get it right that I have to install latest
> drivers on client computers from the link your provided?
> Thanks,
> Igor
>
> "David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
> message news:O$2MO8jCGHA.2664@.TK2MSFTNGP15.phx.gbl...
>
Showing posts with label helloi. Show all posts
Showing posts with label helloi. Show all posts
Tuesday, March 27, 2012
Connecting to SQL Server 2005
Hello!
I was wondering if I need to install something on the client in order to
establish ODBC/OLEDB connection to SQL Server 2005. Currently, I have ADO
2.6 installed. Are there any changes in ODBC/OLEDB drivers for SQL Server
2005?
Thanks,
Igor
Hi
It is best to use MDAC 2.8, but 2.6 will connect to SQL Server 2005, but you
will not be able to use the new datatypes that SQL Server 2005 has
introduced.
The ODBC/OLEDB drivers no longer ship with SQL Server, as it is now a
function of the Operating System to update them.
The new way to connect to SQL Server 2005 is SQL Native Client (SQLNCLI)
"Provider=SQLNCLI"
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"imarchenko" <igormarchenko@.hotmail.com> wrote in message
news:ulvm%23pcCGHA.2300@.TK2MSFTNGP15.phx.gbl...
> Hello!
> I was wondering if I need to install something on the client in order
> to establish ODBC/OLEDB connection to SQL Server 2005. Currently, I have
> ADO 2.6 installed. Are there any changes in ODBC/OLEDB drivers for SQL
> Server 2005?
> Thanks,
> Igor
>
|||"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:%2326c1IiCGHA.3984@.TK2MSFTNGP14.phx.gbl...
> Hi
> It is best to use MDAC 2.8, but 2.6 will connect to SQL Server 2005, but
> you will not be able to use the new datatypes that SQL Server 2005 has
> introduced.
> The ODBC/OLEDB drivers no longer ship with SQL Server, as it is now a
> function of the Operating System to update them.
> The new way to connect to SQL Server 2005 is SQL Native Client (SQLNCLI)
> "Provider=SQLNCLI"
>
This is not quite right. MDAC is part of the operating system, but SQL
Native Client is not.
The SQL Native Client is a seperate install. It is included in the SQL
Server distribution and available here:
http://msdn.microsoft.com/data/sqlnative/default.aspx
There are now 3! OleDb providers for SQL Server. Two in MDAC: MSDASQL
(deprecated) and SQLOLEDB (current). Plus one in the SQL Native Client
(SQLNCLI). SQLNCLI is the best, but you must install it.
SQL Native Client also has a new ODBC driver.
David
|||David,
I am able to connect to SQL Server 2005 using SQL Native Client but
I got en error 'Server unavailable or access denied ...' when trying to
connect using Microsoft OLE DB provider for SQL Server. I am trying to
connect by setting up properties of UDL file on the same box where SQL
Server is installed. Did I get it right that I have to install latest
drivers on client computers from the link your provided?
Thanks,
Igor
"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
message news:O$2MO8jCGHA.2664@.TK2MSFTNGP15.phx.gbl...
> "Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
> news:%2326c1IiCGHA.3984@.TK2MSFTNGP14.phx.gbl...
> This is not quite right. MDAC is part of the operating system, but SQL
> Native Client is not.
>
> The SQL Native Client is a seperate install. It is included in the SQL
> Server distribution and available here:
> http://msdn.microsoft.com/data/sqlnative/default.aspx
> There are now 3! OleDb providers for SQL Server. Two in MDAC: MSDASQL
> (deprecated) and SQLOLEDB (current). Plus one in the SQL Native Client
> (SQLNCLI). SQLNCLI is the best, but you must install it.
> SQL Native Client also has a new ODBC driver.
> David
>
|||David,
I wa able to connect by enabling remote connections using Surface Area.
Thanks,
Igor
"imarchenko" <igormarchenko@.hotmail.com> wrote in message
news:%23t2FLdxCGHA.724@.TK2MSFTNGP10.phx.gbl...
> David,
> I am able to connect to SQL Server 2005 using SQL Native Client but
> I got en error 'Server unavailable or access denied ...' when trying to
> connect using Microsoft OLE DB provider for SQL Server. I am trying to
> connect by setting up properties of UDL file on the same box where SQL
> Server is installed. Did I get it right that I have to install latest
> drivers on client computers from the link your provided?
> Thanks,
> Igor
>
> "David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
> message news:O$2MO8jCGHA.2664@.TK2MSFTNGP15.phx.gbl...
>
I was wondering if I need to install something on the client in order to
establish ODBC/OLEDB connection to SQL Server 2005. Currently, I have ADO
2.6 installed. Are there any changes in ODBC/OLEDB drivers for SQL Server
2005?
Thanks,
Igor
Hi
It is best to use MDAC 2.8, but 2.6 will connect to SQL Server 2005, but you
will not be able to use the new datatypes that SQL Server 2005 has
introduced.
The ODBC/OLEDB drivers no longer ship with SQL Server, as it is now a
function of the Operating System to update them.
The new way to connect to SQL Server 2005 is SQL Native Client (SQLNCLI)
"Provider=SQLNCLI"
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"imarchenko" <igormarchenko@.hotmail.com> wrote in message
news:ulvm%23pcCGHA.2300@.TK2MSFTNGP15.phx.gbl...
> Hello!
> I was wondering if I need to install something on the client in order
> to establish ODBC/OLEDB connection to SQL Server 2005. Currently, I have
> ADO 2.6 installed. Are there any changes in ODBC/OLEDB drivers for SQL
> Server 2005?
> Thanks,
> Igor
>
|||"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:%2326c1IiCGHA.3984@.TK2MSFTNGP14.phx.gbl...
> Hi
> It is best to use MDAC 2.8, but 2.6 will connect to SQL Server 2005, but
> you will not be able to use the new datatypes that SQL Server 2005 has
> introduced.
> The ODBC/OLEDB drivers no longer ship with SQL Server, as it is now a
> function of the Operating System to update them.
> The new way to connect to SQL Server 2005 is SQL Native Client (SQLNCLI)
> "Provider=SQLNCLI"
>
This is not quite right. MDAC is part of the operating system, but SQL
Native Client is not.
The SQL Native Client is a seperate install. It is included in the SQL
Server distribution and available here:
http://msdn.microsoft.com/data/sqlnative/default.aspx
There are now 3! OleDb providers for SQL Server. Two in MDAC: MSDASQL
(deprecated) and SQLOLEDB (current). Plus one in the SQL Native Client
(SQLNCLI). SQLNCLI is the best, but you must install it.
SQL Native Client also has a new ODBC driver.
David
|||David,
I am able to connect to SQL Server 2005 using SQL Native Client but
I got en error 'Server unavailable or access denied ...' when trying to
connect using Microsoft OLE DB provider for SQL Server. I am trying to
connect by setting up properties of UDL file on the same box where SQL
Server is installed. Did I get it right that I have to install latest
drivers on client computers from the link your provided?
Thanks,
Igor
"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
message news:O$2MO8jCGHA.2664@.TK2MSFTNGP15.phx.gbl...
> "Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
> news:%2326c1IiCGHA.3984@.TK2MSFTNGP14.phx.gbl...
> This is not quite right. MDAC is part of the operating system, but SQL
> Native Client is not.
>
> The SQL Native Client is a seperate install. It is included in the SQL
> Server distribution and available here:
> http://msdn.microsoft.com/data/sqlnative/default.aspx
> There are now 3! OleDb providers for SQL Server. Two in MDAC: MSDASQL
> (deprecated) and SQLOLEDB (current). Plus one in the SQL Native Client
> (SQLNCLI). SQLNCLI is the best, but you must install it.
> SQL Native Client also has a new ODBC driver.
> David
>
|||David,
I wa able to connect by enabling remote connections using Surface Area.
Thanks,
Igor
"imarchenko" <igormarchenko@.hotmail.com> wrote in message
news:%23t2FLdxCGHA.724@.TK2MSFTNGP10.phx.gbl...
> David,
> I am able to connect to SQL Server 2005 using SQL Native Client but
> I got en error 'Server unavailable or access denied ...' when trying to
> connect using Microsoft OLE DB provider for SQL Server. I am trying to
> connect by setting up properties of UDL file on the same box where SQL
> Server is installed. Did I get it right that I have to install latest
> drivers on client computers from the link your provided?
> Thanks,
> Igor
>
> "David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
> message news:O$2MO8jCGHA.2664@.TK2MSFTNGP15.phx.gbl...
>
Saturday, February 25, 2012
Connecting Sql Server 2005 on Windows 2003 using ASP local
Hello!
I'm migrating an IIS/SQL-Server application from Windows NT4.0 and SQL-
Server 2000 to Windows 2003 Server and SQL-Server 2005.
Error messages? Connection strings?
But what happens? Does it wait for 15 seconds and give up? Or does attempts
to use the connection fail?
>
>
>
>
>
But what happens? Does it wait for 15 seconds and give up? Or does attempts
to use the connection fail?
>
And why use a DSN? Personally, I've never liked DSNs, it just one more
source of error. What is in that DSN?
>
What happens if you change the DSN part to Provider=SQLNCLI?
>
Where does the password come from? Is it hard-coded into the
application, or user-entered? Keep in mind that in SQL 2005, passwords
are always case-sensitive.
>
--
Erland Sommarskog, SQL Server MVP, esq...@.sommarskog.se
>
Books Online for SQL Server 2005 athttp://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books...
Books Online for SQL Server 2000 athttp://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
It seems that it does not wait for 15 seconds - it returns at once.
The password is hard coded. Changing to SQLNCLI doesn't change
anything. Using the same ASP-application on a remote IIS without
changing anything works fine. Using a wrong password in the ODBC-
Configuration to get additional configuration options produces an
entry in the error log of the SQL-Server, which tells that the
password is wrong. Using a wrong password in the DSN for the ASP-
application does not result in an error log entry.|||(kk035@.hotmail.com) writes:
You are talking about the ODBC applet in the Control Panel?
A password in the DSN? Didn't you also have a password in the connection
string?
I'm migrating an IIS/SQL-Server application from Windows NT4.0 and SQL-
Server 2000 to Windows 2003 Server and SQL-Server 2005.
My problem is that it is not possible to connect local (IIS and SQL-
Server 2005 are runnng on the same node) using ODBC. Running the
applikation on a remote IIS (XPPro) all works fine. I can't see any
differences in the ODBC-configuration.
Any idea?
Thanks(kk035@.hotmail.com) writes:
Quote:
Originally Posted by
I'm migrating an IIS/SQL-Server application from Windows NT4.0 and SQL-
Server 2000 to Windows 2003 Server and SQL-Server 2005.
>
My problem is that it is not possible to connect local (IIS and SQL-
Server 2005 are runnng on the same node) using ODBC. Running the
applikation on a remote IIS (XPPro) all works fine. I can't see any
differences in the ODBC-configuration.
Error messages? Connection strings?
Running IIS and SQL Server on the same machine is not a very good idea,
from the point of view of performance and security. The latter is
particularly critical, if the web application is on the internet.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||It's just an internal application without any performance problems.
strConnect="DSN=ODBC-datasourcename;UID=username;PWD=password"
code snippet:
set conDb = Server.CreateObject("adodb.connection")
conDb.Open Session("strConnect")
for each errDb in conDb.Errors
if errDb.Number <0 then
bDbError = true
Session("strErrTxt1") = errDb.Description
Session("strErrTxt2") = errDb.Source
Session("strErrTxt3") = errDb.SQLState
Session("strErrNbr1") = errDb.Number
Session("strErrNbr2") = errDb.NativeError
exit for
end if
errDb.Clear
next
-err.Db contains no information|||(kk035@.hotmail.com) writes:
Quote:
Originally Posted by
It's just an internal application without any performance problems.
>
strConnect="DSN=ODBC-datasourcename;UID=username;PWD=password"
>
code snippet:
>
set conDb = Server.CreateObject("adodb.connection")
conDb.Open Session("strConnect")
for each errDb in conDb.Errors
if errDb.Number <0 then
bDbError = true
Session("strErrTxt1") = errDb.Description
Session("strErrTxt2") = errDb.Source
Session("strErrTxt3") = errDb.SQLState
Session("strErrNbr1") = errDb.Number
Session("strErrNbr2") = errDb.NativeError
exit for
end if
errDb.Clear
next
>
-err.Db contains no information
But what happens? Does it wait for 15 seconds and give up? Or does attempts
to use the connection fail?
And why use a DSN? Personally, I've never liked DSNs, it just one more
source of error. What is in that DSN?
What happens if you change the DSN part to Provider=SQLNCLI?
Where does the password come from? Is it hard-coded into the
application, or user-entered? Keep in mind that in SQL 2005, passwords
are always case-sensitive.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||On 17 Feb., 15:55, Erland Sommarskog <esq...@.sommarskog.sewrote:
Quote:
Originally Posted by
(k...@.hotmail.com) writes:
Quote:
Originally Posted by
It's just an internal application without any performance problems.
>
Quote:
Originally Posted by
strConnect="DSN=ODBC-datasourcename;UID=username;PWD=password"
>
Quote:
Originally Posted by
code snippet:
>
Quote:
Originally Posted by
set conDb = Server.CreateObject("adodb.connection")
conDb.Open Session("strConnect")
for each errDb in conDb.Errors
if errDb.Number <0 then
bDbError = true
Session("strErrTxt1") = errDb.Description
Session("strErrTxt2") = errDb.Source
Session("strErrTxt3") = errDb.SQLState
Session("strErrNbr1") = errDb.Number
Session("strErrNbr2") = errDb.NativeError
exit for
end if
errDb.Clear
next
>
Quote:
Originally Posted by
-err.Db contains no information
>
But what happens? Does it wait for 15 seconds and give up? Or does attempts
to use the connection fail?
>
And why use a DSN? Personally, I've never liked DSNs, it just one more
source of error. What is in that DSN?
>
What happens if you change the DSN part to Provider=SQLNCLI?
>
Where does the password come from? Is it hard-coded into the
application, or user-entered? Keep in mind that in SQL 2005, passwords
are always case-sensitive.
>
--
Erland Sommarskog, SQL Server MVP, esq...@.sommarskog.se
>
Books Online for SQL Server 2005 athttp://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books...
Books Online for SQL Server 2000 athttp://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
It seems that it does not wait for 15 seconds - it returns at once.
The password is hard coded. Changing to SQLNCLI doesn't change
anything. Using the same ASP-application on a remote IIS without
changing anything works fine. Using a wrong password in the ODBC-
Configuration to get additional configuration options produces an
entry in the error log of the SQL-Server, which tells that the
password is wrong. Using a wrong password in the DSN for the ASP-
application does not result in an error log entry.|||(kk035@.hotmail.com) writes:
Quote:
Originally Posted by
It seems that it does not wait for 15 seconds - it returns at once.
The password is hard coded. Changing to SQLNCLI doesn't change
anything. Using the same ASP-application on a remote IIS without
changing anything works fine. Using a wrong password in the ODBC-
Configuration to get additional configuration options produces an
entry in the error log of the SQL-Server,
You are talking about the ODBC applet in the Control Panel?
Quote:
Originally Posted by
Using a wrong password in the DSN for the ASP-
application does not result in an error log entry.
A password in the DSN? Didn't you also have a password in the connection
string?
I still don't know why you think the connection failed.
If you leave out "if errDb.Number <0 then" do you get anything in
your Session array?
When you changed to SQLNCLI, did you remove the DSN reference?
What happens if you add "SERVER=bogus;" to the connection string?
What happens if you replace UID and PWD with "Integrated Security=SSPI;"?
Since I don't have to access to your system I have to ask questions in
the dark. Please keep this in mind when you answer the questions, and
try to be as clear and unambiguous as possible. It's enough of a guessing
game for me anyway.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx
Subscribe to:
Posts (Atom)