Quelle est la différence entre Trusted_Connection et Integrated Security dans une chaîne de connexion?

Question

Je suis curieux de savoir quelle est la différence entre le jeton "Trusted_Connection" et "Integrated Security" dans les chaînes de connexion SQL Server (je crois que d'autres bases de données/pilotes ne les prennent pas en charge). Je comprends qu'ils sont équivoques.

Answer 1

Ils sont synonymes l'un pour l'autre et peuvent être utilisés intercha négativement.

Dans .Net, il y a une classe appelée SqlConnectionStringBuilder qui est très utile pour traiter chaînes de connexion SQL Server utilisant les propriétés de typées pour construire parties de la chaîne. Cette classe conserve une liste interne des synonymes il peut la carte d'une valeur à une autre:

 
+----------------------+-------------------------+ 
| Value    | Synonym     | 
+----------------------+-------------------------+ 
| app     | application name  | 
| async    | asynchronous processing | 
| extended properties | attachdbfilename  | 
| initial file name | attachdbfilename  | 
| connection timeout | connect timeout   | 
| timeout    | connect timeout   | 
| language    | current language  | 
| addr     | data source    | 
| address    | data source    | 
| network address  | data source    | 
| server    | data source    | 
| database    | initial catalog   | 
| trusted_connection | integrated security  | 
| connection lifetime | load balance timeout | 
| net     | network library   | 
| network    | network library   | 
| pwd     | password    | 
| persistsecurityinfo | persist security info | 
| uid     | user id     | 
| user     | user id     | 
| wsid     | workstation id   | 
+----------------------+-------------------------+ 

_{(Compilé avec l'aide de réflecteur)}

Il existe d'autres classes similaires pour traiter ODBC et OleDb connexion chaînes de caractères, mais malheureusement rien pour les autres fournisseurs de base de données - je suppose que le fardeau est sur la bibliothèque d'un fournisseur pour fournir une telle implémentation.

Answer 2

Ce sont les mêmes.

Malheureusement, il existe plusieurs variantes comme celui-ci, y compris:

Server/Data Source

Base de données/Catalogue initial

Je ne suis pas sûr de l'origine des variations, je suppose que certains sont censés être génériques (pas centrés sur la base de données, donc votre chaîne de connexion serait très similaire si vous vous connectez à un SGBDR ou à un service de répertoire, etc.)

Answer 3

Donc, un peu plus tard, j'ai découvert les origines du nom de conflit. Un ensemble de jetons a été utilisé par ODBC et un ensemble différent défini pour OLEDB. Pour Sql Server pour des raisons héritées, ils supportent toujours les deux de façon interchangeable. Trusted_Connection = true est ODBC et Integrated Security = SSPI était OLEDB.

Answer 4

Dans mon cas, j'ai découvert une différence entre "Trusted_Connection" et "Integrated Security". J'utilise Microsoft SQL Server 2005. À l'origine, j'ai utilisé la connexion Windows (Integrated Security = SSPI). Mais lorsque j'ai remplacé l'authentification Windows par l'authentification SQL Server en ajoutant l'ID utilisateur et le mot de passe, le remplacement de SSPI par "False" a échoué. Il a renvoyé une "erreur générée par l'opération OLE DB en plusieurs étapes". Cependant, quand j'ai remplacé "Integrated Security = False" par "Trusted_Connection = no", cela a fonctionné.