在前面的文章中我已經講到使用同義詞的方法來在SQL Server 2005下連接Oracle，我們可以使用同義 詞在SQL Server 2005下連接Oracle來實時訪問Oracle數據庫，但是如果Oracle中的表數據流較大則會影 響應用系統的性能，於是應采用數據庫作業每天定時執行：
drop table abc--刪除舊表
go
select * into abc
from aaa--aaa為同義詞
from aaa--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為：
TRUNCATE TABLE abc--清除表abc內容
go
insert into abc--將同義詞aaa中的數據插入abc表
select *
from aaa
這樣問題是解決了，但是造成兩邊查詢出的數據不相同的原因是什麼呢？這個我還不知道。
