The same applies for Web Services, correct?

We can suggest configurations all we want to customers, but if they want to use a Trusted Connection, then they're going to do it. <g> So, I needed to figure out how to get it to work, regardless of whether I do it that way or not.

If you read the other posts in this thread, you'll see that I solved the issue by adding the login MyComputerName\ASPNET to my Sql Server security. I assume this was the correct way to handle it. It works anyway. <g>

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

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