Domain user can't hit SQL Server

Hello,
I have a user on Windows 2000 running an application written in VB.net
that uses a config file with a connection string to hit a SQL 2000 DB
running on a Windows 2000 Server box. The connection string looks
something like this:
Provider=SQLOLEDB;Server=MyServer;Databa
se=MYDB;Persist Security
Info=False;User Id=shipio;
When the user tries to perform a task that requires a DB connection, a
message pops up saying that Domain\UserAccount does not have permissions
to access the SQL server. However, there is a sql server username and
password in the connection string. Why doesn't it user it?
The application works fine when it's installed on Win XP PCs, but it
doesn't work on a win 2000 PC. Does Win2000 have a different need for
connection strings? Or does it by default send the domain account to
the sql server?
Any thoughts are greatly appreciated.
Thanks
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!Connection strings that pass a username are for Standard SQL
Authentication. Not Windows Authentication.
Check the Authentication Mode of SQL. It appears to be set to Windows Auth
only. I you intend on using Standard SQL Security, then your
Server settings for SQL need to be changed to allow both.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||This is actually only a problem on the Windows 2000 pc. The sql server
is set up for windows and sql server authentication. We have 20 other
users on Windows XP where this works fine. It's just the 2000 box that
gets the error.
Does the connection string maybe need some additional properties for it
to work on 2000?
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!|||Try connecting from the Windows 2000 client using Query Analyser or OSQL
with a Trusted Connection.
OSQL -SserverNameHere -E -Q"Select @.@.version"
Do you receive the same error?
Try using Standard Security.
OSQL -SserverNameHere -Uuserid -Ppassword -Q"Select @.@.version"
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.