>Still, I don't understand why I didn't need to do anything for a 1.1 Web Service.

Maybe you have some sort of Impersonation configured in the 1.1 web.config file.

You will always need to make sure that the account running in IIS has access to the database if you use a trusted connection. This is why this is a really bad idea ESPECIALLY if you do have some sort of Impersonation configured. It'll chew through connections in a hurry as each different user gets his own SQL connection pool.


+++ Rick---

>
>~~Bonnie
>
>
>
>>You really shouldn't use a trusted connection for Web applications except in development. There are issues with connection pooling that makes this much less efficient than using a username and password combination.
>>
>>That said if you use a trusted connection you need to use the right account. The easiest way to see what account that is run your app and put
>>
>>< %= Environment.Username % >
>>
>>in a page - that's the underlying system account that's running your app - usually NETWORK SERVICE or ASPNET or whatever is set up on an IIS 6 Application Pool.
>>
>>If you're running with the built-in Web Server the account is some other account that Visual Studio uses.
>>
>>
>>+++ Rick ---
>>
>>
>>>I'm sure this is a known problem, but I can't seem to find the fix.
>>>
>>>My VS2005 app connects to the SQL Server database through web services. If I connect with a connection string that uses userid and password, no problem. But, if I change that to use a Trusted_Connection instead, it won't work.
>>>
>>>This worked fine when the app was compiled under VS2003, but has not since migrating it to VS2005. Is there some setting I need to tweak somewhere? In IIS maybe? This is only a problem with Web Services.
>>>
>>>TIA,
>>>
>>>~~Bonnie