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

Nope. No Impersonation, unless there's someplace else to set it up besides the web.config.

~~Bonnie


>>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