Cannot Connect to SQL Server 2000 using Windows XP Pro account login info

When I try to create a System DSN connection to our SQL Server 2000
database that is installed on a Windows 2000 machine, I keep on
getting the following error:
Connection failed:
SQLState: '28000'
SQL Server Error: 18452
[Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user
'(null)'. Reason: Not associated with a trusted SQL Server connection.
We do not have IIS or any web server installed on the database server
machine or the Windows XP Professional machine that is trying to
connect to the Windows 2000 machine. The machines can all see each
other, and we are actually have the machines networked via the
Workgroup setting, not using the Domain setting. Anyone have any ideas
as to what can be the issue?
Thanks,
Jay
(patel@.cs.utk.edu)
Hi Patel,
Since you're not in a domain, Windows Authentication works very
differently. Windows Authentication is commonly used while you're in a
domain and the client has been authenticated on the domain. The error
message "null" indicates that we're unable to "impersonate" the client in
order to make a Windows Authenticated connection.
You have two optioins.
1. Duplicate the nt username & password on both machines and Use Named
Pipes to Connect.
2. Use SQL Standard Security instead of using Windows Authentication.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
|||Kevin,
How do I create a named pipe? I am not sure as to how to do that.
-Jay
(patel@.cs.utk.edu)
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
|||Named pipes are not created, but rather enabled - with both the
Client and Server Network Utilities.
For the Client Network Utility, start it by Start>Run>cliconfg.exe.
The left pane shows disabled protocols. The right pane shows enabled
protocols. In the left pane, click on Named Pipes and then use the
Enable button between the two panes.
For the Server Network Utility (at least for an MSDE version) find the
file SVRNETCN.EXE. Double click to start and the perform the same
actions as in the Client Network Utility, but for the server instance
in question. If you have installed the server as the default instance,
it will have no name, so its just the computer name that will appear
in the server name pull-down list.
If you have a firewall installed on the machines in question, please
say so, since there will be rules to create to open ports if you have
not done so already.
You should also see the article:
Potential causes of the "SQL Server does not exist or access denied"
error message
http://support.microsoft.com/default...06&Product=sql
Lou Arnold
Ottawa, Canada.
On Wed, 21 Jul 2004 21:15:32 -0700, Jay Patel <patel@.cs.utk.edu>
wrote:

>Kevin,
> How do I create a named pipe? I am not sure as to how to do that.
>-Jay
>(patel@.cs.utk.edu)
>*** Sent via Developersdex http://www.codecomments.com ***
>Don't just participate in USENET...get rewarded for it!
|||Kevin,
Your option 1 below implies that you need Named pipes if you have no
domain controller and want Windows Authentication mode. Is that
correct? If so, is this requirement documented somewhere?
Lou Arnold
On Thu, 22 Jul 2004 00:31:06 GMT, kevmc@.online.microsoft.com (Kevin
McDonnell [MSFT]) wrote:

>Hi Patel,
> Since you're not in a domain, Windows Authentication works very
>differently. Windows Authentication is commonly used while you're in a
>domain and the client has been authenticated on the domain. The error
>message "null" indicates that we're unable to "impersonate" the client in
>order to make a Windows Authenticated connection.
>You have two optioins.
>1. Duplicate the nt username & password on both machines and Use Named
>Pipes to Connect.
>2. Use SQL Standard Security instead of using Windows Authentication.
>Thanks,
>Kevin McDonnell
>Microsoft Corporation
>This posting is provided AS IS with no warranties, and confers no rights.
>
>
|||Hey There,
When I try to connect using the Named Pipes, I have pipes enabled on
both the client and server end, with the server pipe being
"\\.\pipe\sql\query" and trying to keep the client pipe the same as
above. When I try to connect, I get this error:
Attempting connection
[Microsoft][ODBC SQL Server Driver][Named Pipes]SQL Server does not
exist or access denied.
TESTS FAILED!
I have added the user and password that I am logged into now on XP Pro
onto the Windows 2000 Server machine. What do you think I am missing?
-Jay
(patel@.cs.utk.edu)
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
|||Hey There,
I have tried the procedure that was suggested. I have added the user name
and password that I am logged in as on my Windows XP Pro machine to the
Windows 2000 Server machine that has SQL Server 2000 installed on it. I have
also created the same username and password on SQL Server 2000 as a valid
user. I have enabled pipes on the server and client with the server pipe
being the default pipe: "\\.\pipe\sql\query" and I have set the client pipe
to the same value. Now I get this error when I try to do a test connection:
Attempting connection
[Microsoft][ODBC SQL Server Driver][Named Pipes]SQL Server does not exist or
access denied.
TESTS FAILED!
What else could I be missing?
-Jay
(jay@.doityourself.com)
Lou_Arnold@.nospam.com (Lou Arnold) wrote in message news:<40ff4f17.8220370@.nntp.flfrd.phub.net.cable.r ogers.com>...[vbcol=seagreen]
> Kevin,
> Your option 1 below implies that you need Named pipes if you have no
> domain controller and want Windows Authentication mode. Is that
> correct? If so, is this requirement documented somewhere?
> Lou Arnold
> On Thu, 22 Jul 2004 00:31:06 GMT, kevmc@.online.microsoft.com (Kevin
> McDonnell [MSFT]) wrote:
|||Jay...
I can't help you further with your problem, sorry. However at least
you have an error messge. Perhaps Kevin can help.
I am slowly coming to the conclusion that Windows Authentication
doesn't work unless you operate a domain controller. If your situation
permits, you may want to try connecting those two computers into a
network with a domain controller.
My only other suggestion is that you try this same test with the sql
server in mixed or SQL Server mode (the alternatives to Windows
Authentication) and see what happens . I'm not sure how to change the
mode after installation.
Lou.
PS Whatever happens, please let us know. It would be of great value to
me to have the information.
On Thu, 22 Jul 2004 00:31:06 GMT, kevmc@.online.microsoft.com (Kevin
McDonnell [MSFT]) wrote:

>Hi Patel,
> Since you're not in a domain, Windows Authentication works very
>differently. Windows Authentication is commonly used while you're in a
>domain and the client has been authenticated on the domain. The error
>message "null" indicates that we're unable to "impersonate" the client in
>order to make a Windows Authenticated connection.
>You have two optioins.
>1. Duplicate the nt username & password on both machines and Use Named
>Pipes to Connect.
>2. Use SQL Standard Security instead of using Windows Authentication.
>Thanks,
>Kevin McDonnell
>Microsoft Corporation
>This posting is provided AS IS with no warranties, and confers no rights.
>
>
|||Lou,
Thanks for the advice. The reason I would really like to use Windows
Authentication is that when I use the SQL Server Authentication, with
some of the machines, it will prompt you to input the password every
single time you select a database table, or click a form button. It
seems that every move that is made requires that SQL needs to have the
password input.
-Jay
(patel@.cs.utk.edu)
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
|||Hi Patel,
Let's try to get a better error message. Try to make the Named Pipe
connection using a Test ODBC Data Source.
When you create a new ODBC DSN, the wizard will walk you through and
generate a much better error message if it fails.
What we need is the OS Error number.
Example: OS Error 53 == Network name not found
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.