2019.5.23 更新
突然发现原来是是sqlnet.ora在搞鬼,只要将SQLNET.AUTHENTICATION_SERVICES=(nts) 改为 SQLNET.AUTHENTICATION_SERVICES=(NONE) 就可以了。
百度关于SQLNET.ORA 的有关信息
ODT对该异常的提示信息又不恰当,导致我们在原地打转。正确的异常的应该是提示“Credential retrieval 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兼容性。
认为问题出在Oracle Home。
认为问题出在Microsoft Account 。
第三种方式停用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 retrieval failed的问题,见Credential retrieval failed 的解决方法)。
2. 更换Windows 版本。
|