加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长学院 > MsSql教程 > 正文

SQL Server 2005与Oracle同步注意NUMBER类型转换

发布时间:2020-12-12 09:01:47 所属栏目:MsSql教程 来源:网络整理
导读:在a href="http://www.cnblogs.com/studyzy/archive/2006/12/19/690305.html"gt;前面的文章中我已经讲到使用同义词的方法来在SQL Server 2005下连接Oracle,我们可以使用同义词来实时访问Oracle数据库,但是如果Oracle中的表数据流较大则会影响应用系统的性

在<a href="http://www.cnblogs.com/studyzy/archive/2006/12/19/690305.html"&gt;前面的文章中我已经讲到使用同义词的方法来在SQL Server 2005下连接Oracle,我们可以使用同义词来实时访问Oracle数据库,但是如果Oracle中的表数据流较大则会影响应用系统的性能,于是我采用数据库作业每天定时执行:
?
<div style="border-right: #cccccc 1px solid; padding-right: 5px; border-top: #cccccc 1px solid; padding-left: 4px; font-size: 13px; padding-bottom: 4px; border-left: #cccccc 1px solid; width: 98%; word-break: break-all; padding-top: 4px; border-bottom: #cccccc 1px solid; background-color: #eeeeee">
<img src="/Images/OutliningIndicators/None.gif" align="top" alt=""><span style="color: #0000ff">drop<span style="color: #000000">?<span style="color: #0000ff">table<span style="color: #000000">?abc<span style="color: #008080">--<span style="color: #008080">删除旧表<span style="color: #008080"><img src="/Images/OutliningIndicators/None.gif" align="top" alt=""><span style="color: #0000ff">go<span style="color: #000000"><img src="/Images/OutliningIndicators/None.gif" align="top" alt=""><span style="color: #0000ff">select<span style="color: #000000">?<span style="color: #808080">*<span style="color: #000000">?<span style="color: #0000ff">into<span style="color: #000000">?abc<img src="/Images/OutliningIndicators/None.gif" align="top" alt=""><span style="color: #0000ff">from<span style="color: #000000">?aaa<span style="color: #008080">--<span style="color: #008080">aaa为同义词

这样就可以把Oracle中的数据同步到本地的SQL Server数据库中。从而解决跨实例查询的性能问题。 使用这样的方式半年了都没有发现有什么问题,可是最近却发现了一个灵异的现象,在Oracle中有一个表aaa,其中一个字段BILL NUMBER类型(未指定精度和小数数据位),对于这种类型,SQL Server2005中同步的表abc中却被定义为nvarchar(384)的类型!?明明是一个数字类型为什么SQL Server会将其转换为字符串类型呢? 若只是数据类型改变了倒没有什么,我应用程序在处理时转换一下就是了,但是更奇怪的是其中某些数据在Oracle中查出来是12.34567,但是在SQL Server 2005中查出来却成了12.345670543574563452346547546234234543656434...,后面是几十位的小数,简直神奇了!有一行数据在Oracle中是1,而在SQL Server中查出来是0.99999999999999999999999999999999...但是这种数据也很少发生,在数万条数据中可以找到2-3条这种几十位小数的数据。 正是这种数据的存在使得应用程序有时算出来的结果和Oracle那边的系统算出来的结果无法匹配。 经测试,如果Oracle中指定了NUMBER类型的精度和小数位数比如NUMBER(15)这样SQL Server将可以自动将其转换为numeric(15,0)类型。 由于NUMBER类型可以表示1.0 * 10(-130) —— 9.9...9 * 10(125) {38个9后边带88个0} 之间的数据,精确度可以达到小数点后38位小数,由于SQL Server中没有如此高精度的数据类型,所以在没有指定NUMBER精度和小数位的情况下SQL Server会将其转换为字符串类型以满足长度和精度的需要。 解决办法就是将SQL Server中同步表的nvarchar(384)类型修改为decimal类型或numeric类型,同步时不删除表,只是清除表内容,然后插入数据。同步SQL为: 这样问题是解决了,但是造成两边查询出的数据不相同的原因是什么呢?这个我还不知道。

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读