连接字符串中的Trusted_Connection和Integrated Security有什么区别？

我很好奇SQL Server连接字符串中的令牌“ Trusted_Connection”和“集成安全性”之间的区别（我相信其他数据库/驱动程序不支持它们）。我了解他们是对等的。

它们彼此是同义词，可以互换使用。

在.Net中，有一个名为SqlConnectionStringBuilder的类，对于使用类型安全属性来构建字符串部分的SQL Server连接字符串处理非常有用。此类保留一个内部同义词列表，以便可以从一个值映射到另一个值：

+ ---------------------- + ------------------------- +
| 价值| 同义词|
+ ---------------------- + ------------------------- +
| 应用| 应用名称|
| 异步| 异步处理|
| 扩展属性| attachdbfilename |
| 初始文件名| attachdbfilename |
| 连接超时| 连接超时|
| 超时| 连接超时|
| 语言| 当前语言
| 地址| 数据源|
| 地址| 数据源|
| 网络地址| 数据源|
| 服务器| 数据源|
| 数据库| 初始目录|
| 信任连接| 综合安全|
| 连接寿命| 负载平衡超时|
| 净 网络库|
| 网络 网络库|
| pwd | 密码
| persistsecurityinfo | 保留安全信息|
| uid | 用户名|
| 用户| 用户名|
| wsid | 工作站编号|
+ ---------------------- + ------------------------- +

_{（在Reflector的帮助下编译）}

还有其他类似的类可用于处理ODBC和OleDb连接字符串，但不幸的是，其他数据库供应商一无所获-我假设供应商的图书馆有责任提供这种实现。

他们是一样的。

不幸的是，有几种这样的变体，包括：

服务器/数据源

数据库/初始目录

我不确定这些变体的起源，我认为其中的一些是通用的（不是以数据库为中心的，因此如果连接到RDBMS与连接到目录服务等，您的连接字符串看起来非常相似）。

不久之后，我发现了名称冲突的由来。ODBC使用了一组令牌，而OLEDB使用了一组不同的令牌。对于Sql Server，由于遗留原因，它们仍然可互换地支持。

Trusted_Connection = true为ODBC，而Integrated Security = SSPI为OLEDB。

就我而言，我发现“ Trusted_Connection”和“集成安全性”之间存在差异。我使用的是Microsoft SQL Server2005。最初，我使用Windows登录（集成安全性= SSPI）。但是，当我用添加用户ID和密码的SQL Server身份验证替换了Windows身份验证时，用“ False”替换SSPI失败了。它返回“多步OLE DB操作生成的错误”。但是，当我用“ Trusted_Connection = no”替换“ Integrated Security = False”时，它起作用了。