分享一個很特別的案例給大家, 這個問題也是一個客戶和Colin提問過的 (當然, 這是公司的案子啦!!), 主要的問題是在於透過Microsoft SQL Server SSIS透過ODBC方式連線到Informix時會發生問題. 最大的問題點是無法寫回到Informix端, 不管是寫文字, 由SQL Server Table取資料寫入, 或是從Informix拉資料下來再寫回去. 這個問題User告知已經困擾了他們多年囉~~ 也找了業界不少顧問來協助處理. 只是問題一直沒有被排除掉....... 最後竟然是採取寫C# Code來進行資料寫入的工作~~ @.@
當時, Colin做了一些測試後, 確實可以重現這樣子的問題. 當然, 一個很基本的觀念是..... 透過OLEDB來進行如何呢? 只是微軟官方已經公開表示, SQL Server 2012將會是最後一個支援OLEDB的版本 >.< 無言吶!!
之後Colin也在G神的協助下, 找到了不少人說明這樣子的一個流程如何進行, 那個站主很不錯, 寫的很詳細啦~~ 只是再看看留言區, 這次收到的問題也一堆人反應, 只是都沒有被解決~~ 難道, Colin一直以來專門解這種怪問題的宿命又來了 >.<
基於Colin與那位作者不認識, 他的站台也沒有寫可以轉PO, 那..... 就把Colin的測試狀況與解決方法丟出來囉~~~ (這篇應該是又臭又長.....)
Colin在此案例測試的環境如下:
* Linux CentOS 5 with Informix 11.5
* Windows Server 2008 R2 x64 with SQL Server 2008 R2 x64
在Informix上Colin建立了二個table, 分別是odbc_source和odbc_destination. 在此測試中, Colin就宜接從Informix取資料下來, 再塞回Informix. 這樣子只要OK了就表示上行下行都可以運作正常, 假若與SQL Server Table端結合遇到問題的話, 那就........ 請洽Microsoft技術支援中心.
SELECT * FROM odbc_source (放了三筆資料)
SELECT * FROM odbc_destination
在Windows Server 的環境上, 要與其他資料庫如Informix伺服器連線, 當然需要先安裝Informix ODBC Driver. Colin在此案例中測試過的版本是clientsdk3.50與clientsdk3.70, 這裡demo的是3.70的版本. 下載請自行到IBM的站台去下載囉 (Colin比較不熟那裡的更新, 怕未來會路徑找不到).
只是..... Windows Server是64位元平台, 可以理解安裝ODBC Driver為64位元版本是合理的. 不過, 此例Colin竟然會說 "請安裝32元位版本的Informix ODBC Driver, 可以與64位元併存"??? 為什麼呢?? 其主要原因是, SSIS程式目前仍只有做到32位元 (很好笑吧~~). 如果沒有使用64位元的Driver會發生下列的錯誤:
安裝Informix ODBC Driver相關的步驟在此就不多說了, 因為都在做 "下一步". 如果對於其中的設定有不清楚的, 也請自行參考安裝程式所提供的相關手冊.
完成Informix ODBC Driver的安裝動作後, 就可以進行Setnet32的連線設定. 這是IBM Informix ODBC Driver的設定工具. 以Colin的環境, 就設定如下:
然後按照IBM官方文件的說法, 要確認ConnectTest Demo能順利的連到Informix資料庫並取回結果, 這樣才算設定正確.
再來設定ODBC了. 由於使用的Informix ODBC版本是32位元的, 所以必須從C:\Windows\SysWOW64\odbcad32.exe來啟動, 不能從控制台調用, 後者是64位元的.
把ODBC的連線設定一下, 並且確認連線是正確的.
緊跟著在SSIS中, 建立一個Package, 其中的流程架構如下:
在這個package中, 需要指定一個連線到Informix的配置, 開啟連線管理員並建立Informix連線的相關設定, 再確認連線成功.
來源端的設定, 就是去取Informix上的test資料庫中的odbc_source資料表.
來源端的設定, 就是去取Informix上的test資料庫中的odbc_destination資料表.
以上設定都完成了後, 看似已經可以正常運作了, 是吧~~ 當按下執行時, 馬上就回應了下列的錯誤:
Colin, 你不是說這個錯誤訊息是安裝64位元的Driver時發生的嗎? 怎麼已經安裝了32位元的Driver, 還是發生這個錯誤呢? 沒錯, 如果使用64位元的Driver會發生這個問題, 但....... 安裝了32位元的Driver, 在SSIS的設定中, 卻預設是 "模擬64位元" 的設定 (@.@很昏, 模擬64位元又不能用64位元的Driver, 算不算BUG!!!), 所以我們要把SSIS Package的專案屬性設定 "Run64BitRuntime" 設為False.
如此就可以排除 "ERROR [IM014] [Microsoft][ODBC 驅動程式管理員] 指定之 DSN 中的驅動程式和應用程式架構不相符" 的錯誤.
快樂的時光總是過的特別快, 才剛完成前一個錯誤, Package也可以正確的執行了, 如果沒有意外, 肯定又會遇到下面這個錯誤:
[ADO NET Destination [19]] 錯誤: 插入資料時發生例外狀況,從提供者傳回的訊息為: ERROR [42000] [Informix][Informix ODBC Driver][Informix]A syntax error has occurred.
[SSIS.Pipeline] 錯誤: SSIS 錯誤碼 DTS_E_PROCESSINPUTFAILED。元件 "ADO NET Destination" (19) 上的 ProcessInput 方法於處理輸入 "ADO NET 目的地輸入" (22) 時失敗,錯誤碼為 0xC020844B。識別的元件從 ProcessInput 方法傳回錯誤。此錯誤是元件特定的錯誤,但屬於嚴重錯誤,將導致資料流程工作停止執行。在此之前可能已公佈過錯誤訊息,說明有關此失敗的詳細資訊。
老實說, 這個錯誤Colin也搞了很久很久, 死活都出錯!!! 後來呢, Colin想到一個地方~~~ 即然是IInformix ODBC Driver發出的錯誤, 然後是Informix端的issue, 那就收集一個ODBC Trace來看看吧~~~ 果然不出所料, 在ODBC Trace中, Colin看到了這樣子的錯誤:
DtsDebugHost fe4-ff0 ENTER SQLExecDirectW
HSTMT 0x008CF1E8
WCHAR * 0x034EDA48 [ -3] "INSERT INTO informix.test ("col1") VALUES (?)\ 0"
SDWORD -3
DtsDebugHost fe4-ff0 EXIT SQLExecDirectW with return code -1 (SQL_ERROR)
HSTMT 0x008CF1E8
WCHAR * 0x034EDA48 [ -3] "INSERT INTO informix.test ("col1") VALUES (?)\ 0"
SDWORD -3
這時Colin就要抱怨一下了, 這個問題後來請微軟協助看一下, 美國那的同仁幫忙測試後, 回了Colin說 "這是IBM Informix的問題". 好吧, 那就丟給IBM Informix Support Team去看一下吧~~ 我把上面寫的東西翻成了英文版, 連圖加完整的測試步驟 (這裡寫的步驟還少些呢....) 都丟出去了, 得到了以下的回覆:
=======================================================
As you can see from the ODBC trace the SQL statement is
being generated by SSIS.
So I believe this is appears to be an SSIS issue.
However I went through and reviewed the different SQLGetInfoW() calls leading up to this SQL to see if the driver is returning an improper response.
I think the one relevant SQLGetInfoW() is to check the SQL_IDENTIFIER_QUOTE_CHAR
DtsDebugHost 2dc-aa4 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS)
HDBC 0x0089EDD0
UWORD 29 <SQL_IDENTIFIER_QUOTE_CHAR>
PTR 0x033264BC [ 2] " "
SWORD 100
SWORD * 0x06A4F3F4 (2)
I believe we are returning the correct value here.
I am not sure of what .Net Framework SSIS is using, but I found a related Microsoft defect that my or may not be relevant here.
http://support.microsoft.com/kb/934055
If this does not resolve the customer's issue, I would recommend they open a case with Microsoft.
===========================================================
這可把Colin我可氣壞了, 我早就和IBM說這是ODBC的問題, 他回我這個和我自己看到的有啥不同? 更好笑的是, 那個KB文件和這次的問題根本沒有關連. 唉~~~
之後Colin秉著測死人不償命的心, 一次又一次的測試, 終於給他搞出來解決的方法了~~~ 哈哈哈~~~ 就是把DELIMIDENT參數為y, 搞定!!!
如此就完成了這次支援專案了~~ 因為Package就順利運作囉~~~ User那經過以上的處理, 也順利的重新架構SSIS, 不再使用C#. 而IBM的支援工程師, 被Colin打了個"非常不滿意", 因為連測試都沒有測試還亂回!! 別忘了, Colin也是在微軟做過技術支援的!!! 客戶的問題要放到心裡去幫忙, 才是王道~~ (有啦有啦, 他老闆有打來關切啦~~~ 只是另一個BUG發上去就沒人鳥了..... 後續有機會Colin再分享怪怪的BUG囉!!)
留言列表