Je ne suis pas sûr à 100 % de ce que vous voulez dire :
Trusted_Connection=True;
EST à l'aide des informations d'identification Windows et équivaut à 100 % à :
Integrated Security=SSPI;
ou
Integrated Security=true;
Si vous ne souhaitez pas utiliser la sécurité intégrée/connexion de confiance, vous devez spécifier explicitement l'identifiant et le mot de passe de l'utilisateur dans la chaîne de connexion (et omettre toute référence à Trusted_Connection ou Integrated Security )
server=yourservername;database=yourdatabase;user id=YourUser;pwd=TopSecret
Seulement dans ce cas, le mode d'authentification SQL Server est utilisé.
Si l'un de ces deux paramètres est présent (Trusted_Connection=true ou Integrated Security=true/SSPI ), puis les identifiants Windows de l'utilisateur actuel sont utilisés pour s'authentifier auprès de SQL Server et de tout user iD= le paramètre sera ignoré et pas utilisé.
Pour référence, consultez le site Connection Strings pour SQL Server 2005 avec de nombreux exemples et explications.
L'utilisation de l'authentification Windows est la méthode préférée et recommandée, mais cela peut entraîner un léger retard car SQL Server devra authentifier vos informations d'identification auprès d'Active Directory (généralement). Je n'ai aucune idée de l'ampleur de ce léger retard, et je n'ai trouvé aucune référence à ce sujet.
Résumé :
Si vous spécifiez soit Trusted_Connection=True; ou Integrated Security=SSPI; ou Integrated Security=true; dans votre chaîne de connexion
==> ALORS (et alors seulement) vous avez l'authentification Windows événement. N'importe quel user id= paramètre dans la chaîne de connexion sera ignoré .
Si vous NE PAS spécifiez l'un ou l'autre de ces paramètres,
==> alors vous NE PAS avoir l'authentification Windows en cours (le mode d'authentification SQL sera utilisé)
