同事報案,某台測試機器原本只裝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適合版本」運作邏輯,在遇到存取權限問題時,不會直接爆出存取被拒,而是略過錯誤導致錯選版本。

想想,這次根本是總複習來著,看看我動用多少知識與經驗:

有種動用畢生所學跟茶包對決的感覺 XD 而面對Oracle Client版本罄竹難書的肇事記錄,我暗暗握拳立誓:

拎杯以後都要改用Managed ODP.NET

拎杯以後都要改用Managed ODP.NET

拎杯以後都要改用Managed ODP.NET


Comments

Be the first to post a comment

Post a comment


32 - 16 =