No Windows, Only SQL Server Authentication

Greetings,
I am unable to log onto the MS SQL Server 2000 using my Windows Login name
and Password from the MS command prompt program locally on a new test
installation Windows Enterprise Server 2003 system. However, if I use an
SQL Server Login and Password, it works every time. The command string I am
using is:
"osql.exe -S (local) -U login_name -P password"
When successful (SQL Authentication), an SQL command prompt is returned.
When unsuccessful (Windows Authentication), the following message is
received:
"Login failed for user login_name"
The SQL Server 2000 installation is enabled for both Windows and SQL
authentication and has been updated to the latest service packs.
The installation is a new test set up to experiment with Web Services using
MS SQL Server. The original problem was the installation of the
"wscrRecordStore" demonstration data base from the book, Programming
Microsoft .NET XML WEB SERVICES, by Foggon et al. However, the problem was
reduced to the simple command line issue above in order to troubleshoot it.
Since I am also the Windows and SQL Server system administrator, I have
tried a wide variety of different login strategies. Only users set up with
SQL Authentication seem to be able to access the SQL Server programatically.
What's the problem? This seems to be a straight forward but stubborn
failure.
Richard Scott
Critical Connections, Inc.To establish a Windows authenticated connection from OSQL, you need to
specify the -E parameter instead of -U and -P. This will use the account of
the currently logged in user. For example:
OSQL -S (local) -E

> Only users set up with SQL Authentication seem to be able to access the
SQL Server programatically.
Your connection string needs to specify the type of authentication desired.
Assuming you are using SqlClient:
Windows authentication:
Data Source=MyServer;Integrated Security=SSPI;Initial
Catalog=MyDatabase
SQL Server authentication:
Data Source=MyServer;User ID=MyLogin;Password=MyPassword;Initial
Catalog=MyDatabase
Also, see the article below for additional information on establishing a
trusted connection from ASP.NET:
http://support.microsoft.com/defaul...989&Product=sql
Hope this helps.
Dan Guzman
SQL Server MVP
"Richard Scott" <rtscott@.pacbell.net> wrote in message
news:6XL6c.12481$zh1.7776@.newssvr27.news.prodigy.com...
> Greetings,
> I am unable to log onto the MS SQL Server 2000 using my Windows Login name
> and Password from the MS command prompt program locally on a new test
> installation Windows Enterprise Server 2003 system. However, if I use an
> SQL Server Login and Password, it works every time. The command string I
am
> using is:
> "osql.exe -S (local) -U login_name -P password"
> When successful (SQL Authentication), an SQL command prompt is returned.
> When unsuccessful (Windows Authentication), the following message is
> received:
> "Login failed for user login_name"
> The SQL Server 2000 installation is enabled for both Windows and SQL
> authentication and has been updated to the latest service packs.
> The installation is a new test set up to experiment with Web Services
using
> MS SQL Server. The original problem was the installation of the
> "wscrRecordStore" demonstration data base from the book, Programming
> Microsoft .NET XML WEB SERVICES, by Foggon et al. However, the problem
was
> reduced to the simple command line issue above in order to troubleshoot
it.
> Since I am also the Windows and SQL Server system administrator, I have
> tried a wide variety of different login strategies. Only users set up
with
> SQL Authentication seem to be able to access the SQL Server
programatically.
> What's the problem? This seems to be a straight forward but stubborn
> failure.
> Richard Scott
> Critical Connections, Inc.
>|||Not sure if this applies to you, but vefiry that the user who is attempting
to connect actually has a login established in SQL Server. You can do this
by expanding the Security folder in Enterprise Manager and looking at the
Logins.
Rand
This posting is provided "as is" with no warranties and confers no rights.