Nie jestem w 100% pewien, co masz na myśli:
Trusted_Connection=True;
Jest przy użyciu poświadczeń systemu Windows i jest w 100% odpowiednikiem:
Integrated Security=SSPI;
lub
Integrated Security=true;
Jeśli nie chcesz używać zintegrowanych zabezpieczeń / zaufanego połączenia, musisz wyraźnie określić identyfikator użytkownika i hasło w ciągu połączenia (i pominąć wszelkie odniesienia do Trusted_Connection lub Integrated Security )
server=yourservername;database=yourdatabase;user id=YourUser;pwd=TopSecret
Tylko w tym przypadku używany jest tryb uwierzytelniania SQL Server.
Jeśli którekolwiek z tych dwóch ustawień jest obecne (Trusted_Connection=true lub Integrated Security=true/SSPI ), a następnie poświadczenia systemu Windows bieżącego użytkownika są używane do uwierzytelniania względem SQL Server i dowolnego user iD= ustawienie zostanie zignorowane, a nie używany.
Aby uzyskać więcej informacji, zobacz witryna Connection Strings dla SQL Server 2005 z wieloma przykładami i objaśnieniami.
Korzystanie z uwierzytelniania systemu Windows jest preferowanym i zalecanym sposobem wykonywania czynności, ale może spowodować niewielkie opóźnienie, ponieważ SQL Server musiałby uwierzytelnić poświadczenia w usłudze Active Directory (zazwyczaj). Nie mam pojęcia, jak duże może być to niewielkie opóźnienie i nie znalazłem żadnych odniesień do tego.
Podsumowując:
Jeśli określisz Trusted_Connection=True; lub Integrated Security=SSPI; lub Integrated Security=true; w ciągu połączenia
==> WTEDY (i tylko wtedy) masz uwierzytelnianie Windows wydarzenie. Dowolny user id= ustawienie w ciągu połączenia zostanie zignorowane .
Jeśli NIE określ jedno z tych ustawień,
==> to NIE trwa uwierzytelnianie Windows (zostanie użyty tryb uwierzytelniania SQL)
