2019.5.23 更新

---

 

突然发现原来是是sqlnet.ora在搞鬼，只要将SQLNET.AUTHENTICATION_SERVICES=(nts)  改为 SQLNET.AUTHENTICATION_SERVICES=(NONE) 就可以了。

 

百度关于SQLNET.ORA 的有关信息

• 详解sqlnet.ora的作用

 

ODT对该异常的提示信息又不恰当，导致我们在原地打转。正确的异常的应该是提示“Credential retrieva l failed”。

错误截图

 

 

同事没有遇到这个问题，很有可能一个原因就是他的ODT不是读取ODT安装后的SQLNET.ORA文件，而是定位到了Oracle Home下的文件，因为他们要运行PL/SQL ，所以先装Oracle Home，之后再安装ODT。 我是直接装ODT没有搞任何东西。

 

 

 

 

原文

---

 

昨天在使用VS通过ODT连接数据库扒模型的时候发现了这个异常。经过测试，发现这个异常是因为 ODT 插件无法识别服务名中的“.”字符 导致的，比如“orcl.asian.com”。其他不包含“.”字符的服务名皆可正常连接。做了下简单的回溯，一个月前的ODT插件是正常工作的，期间数据库未作任何改动。唯独Windows 和Visual Studio更新过。随后测试了相同版本的Visual Studio（Visual Studio Community 2017 15.9.12）在Windows 7 下的连接测试，结果是连接成功。

异常截图

 

Google 中有一些相关的文章，大致围绕在几个点上：

• 认为问题出在OCI兼容性。
  • https://blog.csdn.net/xiaoshubiao/article/details/17243313
  • https://blog.csdn.net/wangliyingwad/article/details/42455497
认为问题出在Oracle Home。
• http://www.cnblogs.com/psforever/p/3929064.html
• https://blog.csdn.net/qq_34968660/article/details/74834568
认为问题出在Microsoft Account 。
• https://blog.csdn.net/kjlrzzyffmx/article/details/77861908?utm_source=blogxgwz5

 

第三种方式停用MS Account 能解决这个问题。自己也顺便用虚拟机做了不同版本的测试，结果不太理想，所有登录的Windows 10都失败了。但同事的1803装183000的ODT就算登录也是能够正常连接，对比不同点有几个：一是VS 2017的版本并非是我测试时的15.9而是Older Version。二是Windows 使用Administrator 登录MS账户。

 

 

使用ODAC替换ODT也可以解决掉这个异常，好奇登录MS 账户之后，Windows 到底进行了些什么操作？一个托管组件为什么会受到MS 账户的影响呢？为什么ODT不行，使用ODAC就可以？先Mark起来，后面有时间再细查。

 

总结

ODT插件是在Visual Studio一启动就加载进内存了，所以，如果是在登录MS 账户之前打开VS，那么ODT仍然是正常工作的，直到你关闭VS。解决这个异常除了上面说的切换MS Account 外，还有下面几个。

1. 使用Oracle Data Access Components（可能会遇到Credential retrieva l failed的问题，见Credential retrieva l failed 的解决方法）。

2. 更换Windows 版本。