Remote connection failed

I am getting the following error ...
Connection failed:
SQLState: '28000'
SQL Server Error: 18452
[Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user
'myUserName'. Reason: Not associated with a trusted SQL Server connection.
Upon examination of the SQL Server Log, I see the exact same message.
The connection string being used is ...
"Driver={SQL Server}; Server=xxx.xxx.xxx.xxx; Address=xxx.xxx.xxx.xxx,1433;
Network=DBMSSOCN; Database=myDatabase"
SQL Server Properties - Security tab has the following settings ...
Authentication: Windows only
Audit level: All
Allow cross-database ownership chaining: not checked
When SQLDriverConnect is called, an SQL Server Login dialog comes up
allowing me to Use Trusted Connection or provide Login ID and Password. If
Use Trusted Connection is checked, then same error as above is returned
except myUserName is replaced by "(null)". If not checked, then the login
has failed with all username/password combinations I know of on my server.
Referencing an earlier posting dated 10/31/2005 entitled "Error connecting
through the web", Sue Hoegemeier wrote, "Use Integrated Security=SSPI with
an OLE DB provider in your connection string instead of supplying a username
and password." Sue, what does this part of the connection string "look"
like? Can you give me an example? Also, how can the Reason given in the
error message be remedied?
Any help would be greatly appreciated. Thanks.
Hi Kris,
1. If you use a trusted connection and the login fails for
user null, the credentials aren't being passed to the
server. The issues with that depend on if you are connecting
across a network and how the client PC is setup in that
network, if you have any network issues which you can find
in the event logs of the PC, etc.
2. You can't use a username/password combination in your
case as the server is setup to use Windows authentication
only. You have to use windows authentication so can't pass a
user name and password as you would do if using SQL Server
login.
3. You are using an ODBC connection instead of OLE DB. For
that connection, use Trusted_connection=Yes. You can find
examples at:
http://www.carlprothman.net/Default...erForSQLServer
-Sue
On Mon, 5 Dec 2005 14:23:04 -0500, "Kris"
<kfraley@.direcway.com> wrote:

>I am getting the following error ...
>Connection failed:
>SQLState: '28000'
>SQL Server Error: 18452
>[Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user
>'myUserName'. Reason: Not associated with a trusted SQL Server connection.
>Upon examination of the SQL Server Log, I see the exact same message.
>The connection string being used is ...
>"Driver={SQL Server}; Server=xxx.xxx.xxx.xxx; Address=xxx.xxx.xxx.xxx,1433;
>Network=DBMSSOCN; Database=myDatabase"
>SQL Server Properties - Security tab has the following settings ...
>Authentication: Windows only
>Audit level: All
>Allow cross-database ownership chaining: not checked
>When SQLDriverConnect is called, an SQL Server Login dialog comes up
>allowing me to Use Trusted Connection or provide Login ID and Password. If
>Use Trusted Connection is checked, then same error as above is returned
>except myUserName is replaced by "(null)". If not checked, then the login
>has failed with all username/password combinations I know of on my server.
>Referencing an earlier posting dated 10/31/2005 entitled "Error connecting
>through the web", Sue Hoegemeier wrote, "Use Integrated Security=SSPI with
>an OLE DB provider in your connection string instead of supplying a username
>and password." Sue, what does this part of the connection string "look"
>like? Can you give me an example? Also, how can the Reason given in the
>error message be remedied?
>Any help would be greatly appreciated. Thanks.
>
|||Thank you for responding Sue.
Since posting yesterday, I have successfully been able to establish a
connection to SQL Server. Apparently, there were several problems, but the
changes necessary to get it working were relatively few and included...
1. In Enterprise Manager, create new username/password login with SQL Server
Authentication.
2. Select Authentication = SQL Server and Windows on Security tab of SQL
Server Properties dialog.
3. Connection string in SQLDriverConnect string is "Driver={SQL Server};
Server=xxx.xxx.xxx.xxx; Address=xxx.xxx.xxx.xxx,1433; Network=DBMSSOCN;
Database=myDatabase; Uid=myNewUsername; Pwd=myNewPassword". Incidentally,
originally, I had actually obtained the connection string used from the
examples listed on the web site you provided below. I think I found that on
another one of your postings. Regardless, thank you for providing that URL.
Special note: I wanted to say a word about your #3 below. I tried using
Trusted_Connection=yes, but it did not work with my remote (over the
internet) connection. Though I am not 100% certain, I believe it may not
have worked because the Windows login username/password on my remote client
PC differs from the Windows login on the Windows Server 2003 machine hosting
the SQL Server.
Anyway, thank you for your postings; I have found them to be very helpful!
Hopefully, it is not too early to wish you a Merry Christmas and happy New
Year.
Kris
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:5lv9p1h2k9a0p810lfo8p16met440o60h0@.4ax.com...
> Hi Kris,
> 1. If you use a trusted connection and the login fails for
> user null, the credentials aren't being passed to the
> server. The issues with that depend on if you are connecting
> across a network and how the client PC is setup in that
> network, if you have any network issues which you can find
> in the event logs of the PC, etc.
> 2. You can't use a username/password combination in your
> case as the server is setup to use Windows authentication
> only. You have to use windows authentication so can't pass a
> user name and password as you would do if using SQL Server
> login.
> 3. You are using an ODBC connection instead of OLE DB. For
> that connection, use Trusted_connection=Yes. You can find
> examples at:
> http://www.carlprothman.net/Default...erForSQLServer
> -Sue
> On Mon, 5 Dec 2005 14:23:04 -0500, "Kris"
> <kfraley@.direcway.com> wrote:
>
|||Hi Kris,
To follow up on the last issue in question with using
windows authentication, like I said in my first reply when
you use that and you get login failed for user null, then
credentials aren't being passed. And that would depend on
the network configuration, etc.
If you are going over a remote connection or are not logging
into the domain where SQL Server is then no, Windows
authentication won't work. It passes your network login
credentials to SQL Server. If you are logged into a
different domain and don't have any type of domain trusts
set up (where different domains can "talk" to each other and
know about each others logins), SQL Server has no way to
verify those credentials. So your guess was correct and
changing the authentication mode to allow a SQL login and
using that would be an option in your case.
And thanks for the kind words!
-Sue
On Tue, 6 Dec 2005 09:29:11 -0500, "Kris"
<kfraley@.direcway.com> wrote:

>Thank you for responding Sue.
>Since posting yesterday, I have successfully been able to establish a
>connection to SQL Server. Apparently, there were several problems, but the
>changes necessary to get it working were relatively few and included...
>1. In Enterprise Manager, create new username/password login with SQL Server
>Authentication.
>2. Select Authentication = SQL Server and Windows on Security tab of SQL
>Server Properties dialog.
>3. Connection string in SQLDriverConnect string is "Driver={SQL Server};
>Server=xxx.xxx.xxx.xxx; Address=xxx.xxx.xxx.xxx,1433; Network=DBMSSOCN;
>Database=myDatabase; Uid=myNewUsername; Pwd=myNewPassword". Incidentally,
>originally, I had actually obtained the connection string used from the
>examples listed on the web site you provided below. I think I found that on
>another one of your postings. Regardless, thank you for providing that URL.
>Special note: I wanted to say a word about your #3 below. I tried using
>Trusted_Connection=yes, but it did not work with my remote (over the
>internet) connection. Though I am not 100% certain, I believe it may not
>have worked because the Windows login username/password on my remote client
>PC differs from the Windows login on the Windows Server 2003 machine hosting
>the SQL Server.
>Anyway, thank you for your postings; I have found them to be very helpful!
>Hopefully, it is not too early to wish you a Merry Christmas and happy New
>Year.
>Kris
>"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
>news:5lv9p1h2k9a0p810lfo8p16met440o60h0@.4ax.com.. .
>