在連接字符串指定爲Oracle（32/64位）微軟ODBC的版本DSN-less連接（訪問2013（32位））

每在連接字符串指定爲Oracle（32/64位）微軟ODBC的版本DSN-less連接（訪問2013（32位））

http://www.accessmvp.com/djsteele/DSNLessLinks.html

我已經嘗試更換DSN-使用無DSN連接在Access中創建表格定義。

沒有運氣試圖從微軟的驅動程序：因爲這個具體問題

微軟ODBC的Oracle

：

https://support.microsoft.com/en-us/kb/942976

在Windows 7 64位，你有使用32位ODBC管理面板管理ODBC驅動程序（DSN），如果您想使用Access 2013 32位。

但是，這並沒有解決問題，因爲我試圖走在無DSN首先。

我假定連接不工作的原因是，Windows是「有益」選擇驅動器的64位版本時，我用這個作爲我的連接字符串：

strConnectionString = _ 
    "ODBC;DRIVER={Microsoft ODBC for Oracle};" & _ 
    "Server=" & ServerName & ";" & _ 
    "UID=" & UID & ";" & _ 
    "PWD=" & PWD & ";"

的問題是我不能指定我想要的32位版本的驅動程序，因爲版本（32和64）具有相同的名稱。

有沒有辦法解決這個問題？

謝謝，乍得。

來源

2016-10-10 C. Lehman

這裏的問題，它是如何解決：那大概開始在Access 97

遺留系統（.mdb）中當前正在訪問2013（.ACCDB）格式。（我們沒有爲在明年之前重新平臺系統的預算）

有數百個與Oracle數據源相關的ODBC表，其中只有少數實際使用。只有15個表格被直接使用或隨後被其他.accdb數據庫鏈接。

問題的根源是，表四一直在使用或者是現在下落不明DSN，一個丟失或過期的用戶ID或密碼錯誤產生。

用戶在他們的一個進程中會看到「ODBC鏈接失敗」消息，必須轉到鏈接表管理器並通過表名查找要重新鏈接的鏈接。（通常他們會選擇全部200個）。

然後，他們會得到提示更新DSN/UID/PWD。

當然，在這樣做的時候，Access 2013並沒有將這些信息保存到tabledefs ...所以每當用戶再次嘗試運行他們的進程時，他們都會再次看到ODBC失敗消息。

解決方案是下降和與上最新DSN重新添加 4個連接的表。

我還在主窗體上添加了一個按鈕，它們通過了ODBC鏈接表（其中只有15個）的簡短列表，並在表def上爲它們運行TableDef(_TABLENAME_).RefreshLink。

謝謝都阿爾伯特和Wernfried的見解。

_{（我希望是replatforms系統存在的所有SQL Server中和/或團隊的一部分，甲骨文（後端），在明年HTML 5的前端，所以這是一個好止損間隙）。}

來源

2016-10-12 17:33:35

沒有混淆的問題，因爲「進程內」x32程序只會加載和使用x32驅動程序。而一個「正在進行中」的x64位程序只會加載和使用x64驅動程序。它們都可以具有相同的名稱，但它們已安裝並位於操作系統的不同位置。

如果您閱讀了鏈接的文章，那麼簡單的解決方案是始終啓動正確版本的ODBC管理器。最簡單的方法是從訪問內部創建鏈接，因爲訪問將始終啓動正確的ODBC管理器。

在一天結束時，由於您使用DSN較少，那麼這進一步意味着您使用的鏈接對您的問題和問題沒有影響。

所以，雖然驅動程序可能有相同的名稱，操作系統和軟件只能使用相同的位大小的軟件，因此將在您的情況下使用。

您希望檢查的唯一問題是在Access中您想要從導入的外部數據選項卡上啓動並鏈接ODBC管理器。此時，您使用該管理器將單個錶鏈接到oracle，然後訪問將抓取（複製）該連接字符串。你注意到如果沒有顯示oracle驅動程序，那麼你必須安裝oracle驅動程序（但可能oracle驅動程序已經存在）。

再經過覈實該鏈接的作品，然後只要按下Ctrl-G跳轉到調試窗口，並用這個命令顯示連接字符串設置：

？ currentdb.TableDefs（「我剛剛鏈接的表」）連接

然後您會看到使用的連接字符串，並且會顯示oracle驅動器的名稱/語法 - 這就是您在連接字符串中使用的。

我還應該指出，從Access啓動ODBC管理器時，「默認」選項卡是「文件數據源」 - 這將始終在Access中創建一個DSN較少的連接。所以默認情況下，Access將始終使用並創建一個無DSN連接。文件數據源僅在創建時使用。一旦你創建了鏈接表，那麼你可以例如將數據庫移動到不同的計算機，並且錶鏈接將繼續正常工作，因爲默認情況下使用DSN鏈接進行訪問（所以信息被「複製」到表def定義連接字符串對於該鏈接表 - 通過ODBC面板保存的那個點上的原始文件數據源將被忽略並且不被使用。

底線：所有這些鏈接指向那些文章並不重要，也不是您的問題或者問題，你只需要使用Access中的GUI創建一個鏈接表，如果這樣，那麼只需按照上面的鏈接表查看連接字符串，它就會顯示/顯示你需要的正確驅動字符串使用

來源

2016-10-10 21:17:42

當創建與「外部數據」功能區中的「ODBC數據庫」選項的文件DSN ...如果我使用Microsoft ODBC對Oracle驅動程序下面是錯誤：「保留錯誤（-7778） ;這個錯誤沒有消息。「如果我使用Oracle驅動程序（instantclient_12_1中的Oracle），它不會連接。 'ODBC - 調用失敗。指定的驅動程序不能被加載由於系統錯誤127：指定的程序無法找到（在Oracle instantclient_12_1; **路徑驅動程序DLL **）。（＃160）' 只有機器dsns似乎工作。 –

從Access啓動ODBC面板（這可以確保您始終使用正確的ODBC設置屏幕，我將從其站點刪除並重新安裝x86 oracle驅動程序，並再次嘗試重新鏈接表格。 DSN無法正常工作，我會嘗試退出Access，然後右鍵單擊Access快捷方式，然後選擇以管理員身份運行，然後再次嘗試ODBC設置，如上所述，請嘗試下載並重新安裝Oracle驅動程序。應該沒有關係 - 但「文件」意味着一個文件被保存 - 正如我指出的文件是更好，因爲它創建一個DSN連接總是 –

謝謝。正如上面Wernfried所述，我採取了不同的方法利用我需要克服的一個問題是重新鏈接TableDef時出現3151錯誤，Access似乎在鏈接表管理器中彈出DSN選擇對話框，然後調用ODBC驅動程序打開自己的對話框UID/PWD。我似乎無法讓第二部分工作。它給了我一個3146. –

您可以在註冊表中檢查驅動程序的位置。在x86（32位）的情況下檢查HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI\Microsoft ODBC for Oracle\Driver。最有可能的值應該是%WINDIR%\system32\msorcl32.dll

現在，如果你遇到一個應用像您的MS Access文件夾%WINDIR%\system32\被自動重定向到%WINDIR%\SysWoW64\（見WoW64），所以你（或MS接入）會發現文件msorcl32.dll在文件夾c:\Windows\SysWOW64\。

原則上，對於x64，您必須檢查註冊表值HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Microsoft ODBC for Oracle\Driver，但是用於Oracle的Microsoft ODBC驅動程序是deprecated，僅適用於32位！如果您需要64位版本，則必須下載並安裝ODBC驅動程序from Oracle。

使用32位ODBC驅動程序，您的32位訪問應該沒有任何問題。

來源

2016-10-11 06:16:36

謝謝你的評論。我決定解決我們遇到的問題，而不是嘗試去DSN-less。傳統Access系統中有大約200個鏈接表，其中許多不再使用。我們沒有預算在明年之前推出系統的重新平臺。我的任務是幫助用戶通過自動重新鏈接ODBC源（多個）來處理不斷丟失的ODBC鏈接的棘手問題，但僅針對少數表。我可以利用DSN，但有時表的連接會返回3151錯誤。在這一點上，我只需要（ct'd）... –

...能夠彈出ODBC驅動程序DSN選擇對話框，以便當鏈接表有3151錯誤時，用戶可以重新選擇他們的機器DSN並重新鏈接表格。這是我所面臨的唯一問題...我發現很難讓機器的DSN對話框從代碼中彈出來，然後通過再次詢問密碼/ UID來修復鏈接。 –

如果你有一個正在使用的連接，並且你「失去了」該連接（一個鏈接表），那麼你必須重新啓動該應用程序。重新鏈接到已經工作的同一個表將嘗試使用剛斷開的連接。 –

在連接字符串指定爲Oracle（32/64位）微軟ODBC的版本DSN-less連接（訪問2013（32位））

回答

相關問題