同事報案，某台測試機器原本只裝Oracle Client 32位元版本，因該主機上的SQL Server x64需建Linked Server連Oracle，故加裝了Oracle Client 64位元版本[參考]。不料，同主機用System.Data.OracleClient讀資料的網頁，在安裝Oracle Client 64位元版後，忽然冒出Oracle 32/64版本不符的經典錯誤：An attempt was made to load a program with an incorrect format。
依先前研究，.NET能依PATH尋找正確版本，確認32及64位元的Oracle Client路徑都有設定，檢查IIS AppPool確定已開啟32位元模式，不應出錯。而且原本網站正常，加裝64位元Oracle Client後出錯尤其難以解釋，案情陷入膠著…
招喚茶包一哥－Process Monitor登場，很快找出問題：IIS AppPool虛擬帳號對Oracle Client目錄下的oci.dll沒有讀取權限，補開權限後，問題終於排除。由於網站設定並未變動，先前可以執行代表原本有開權限，為什麼安裝64位元Oracle Client會變更32位元Oracle Client目錄的權限，則是個謎。但在經驗中，因為Oracle Client目錄權限出錯已不是第一次，相信也不是最後一次。 而從本例可多學到一條「依PATH路徑尋找Oracle Client適合版本」運作邏輯，在遇到存取權限問題時，不會直接爆出存取被拒，而是略過錯誤導致錯選版本。
想想，這次根本是總複習來著，看看我動用多少知識與經驗：
- Oracle Client目錄權限不足造成錯誤
- Incorrect format錯誤
- IIS AppPool啟用32位元件模式
- ODP.NET如何找對Oracle Client檔案
- SQL Server x64 建 Oracle Linked Server
- IIS 7+之NTFS權限設定
- Windows除錯神兵利器－Process Monitor
有種動用畢生所學跟茶包對決的感覺 XD 而面對Oracle Client版本罄竹難書的肇事記錄，我暗暗握拳立誓：
拎杯以後都要改用Managed ODP.NET
拎杯以後都要改用Managed ODP.NET
拎杯以後都要改用Managed ODP.NET