我懷疑你遺漏了我們需要的一些細節。
當您打開第一個表時,是否提示您進行登錄? (這是關鍵信息)。如果您使用「不同」鏈接並在這些鏈接中保存用戶名/密碼,則不應得到任何ODBC提示,因此您可以輕鬆地處理多個區域。
但是,它聽起來像你有一組鏈接,並且想要重新指向/重新鏈接到不同的服務器。這可以工作 - 但不是如果你看到/允許ODBC提示。
如果您在鏈接中包含用戶標識/密碼,那麼您應該可以重新鏈接(切換)到任一系統。但是,當你這樣做時,那麼兩個uid /密碼組合將在同一給定時間處於活動狀態。
問題出在哪裏非常錯誤的是,如果您重新鏈接了不正確的登錄,那麼將使用先前的uid /密碼!事實上,如果您嘗試登錄(甚至是不好的!),那麼將使用第一個合法登錄!在這一天結束時,這意味着這裏的弱點是當/如果你要求登錄時,即使登錄不好,它也會返回「是」以進行合法登錄。 (因爲Access會使用之前的合法登錄)您必須處理此問題。
很可能事情指向您的代碼,在重新鏈接之前執行登錄「測試」。我會建議您的「測試」登錄代碼返回OK,然後執行傳遞查詢以返回數據庫名稱 - 如果該數據庫名稱/服務器錯誤,則拒絕該登錄並且不重新鏈接。
這裏至關重要的是你如何測試新的登錄/服務器?而且你絕對不希望ODBC登錄提示出現 - 因爲如果用戶取消,或輸入錯誤的登錄,那麼你的重鏈接代碼將使用先前的緩存登錄。
您應該可以重新鏈接同一組給定的表並將它們指向另一臺服務器 - 但您需要確保您使用的登錄確實可以正常工作。
最後但並非最不重要: 訪問總是使用DSN較少的連接。唯一的例外是如果您使用的是系統DSN。所以,當你創建一個文件DSN並重新鏈接時,DSN FROM THAT指向被忽略,而不是被使用。 (這使您可以說將應用程序分發到其他桌面,而無需複製/包含DSN)。因此,實際上你總是使用無DSN連接,如果你不是,那麼我建議你轉儲SYSTEM DSN,因爲Access不能使用來自這樣的系統DSN的USER /密碼 - 即使你包含USER /密碼DSN仍然被忽略。
此外,當你重新鏈接,你使用dbAttachSavePWD - 你不應該,但我會爲測試包括它。
如果您使用/允許ODBC驅動程序提示用戶進行登錄 - 那麼您必須消除此問題並確保您的代碼執行登錄。
是很長時間的囉嗦,而且Access也不喜歡那個解決方案。 – 2009-03-10 17:25:30