使用odbc代替c中的sql服務器連接＃

問候和稱呼！我在有開發服務器，QA服務器和生產服務器的環境中工作。我最近遇到了問題，因爲我想在本地工作，並將我的本地開發連接到我們的開發服務器。當我部署到我們的開發服務器時，我希望數據連接繼續連接到我們的開發服務器，但是當我部署到我們的QA或生產時，我希望它連接到位於當前服務器上的數據庫。使用odbc代替c中的sql服務器連接＃

我想出了一個解決方案，使用ODBC數據源連接到SQL而不是使用標準的SQL數據連接是管理這個最簡單的方法。這意味着改變我的連接字符串，並使用odbc ado.net代替SQL ado.net。

我的問題是，使用ODBC連接超過標準SQL連接有什麼缺點，限制或性能損失？這會阻止我稍後使用LINQ/Entity框架嗎？

感謝，保羅

來源

2011-07-15 Paul

有沒有理由不把你的連接字符串存儲在配置文件，只是修改基於環境的配置文件？你的帖子並沒有解釋爲什麼一個標準的sql連接字符串（再次修改爲環境）不起作用。 – AllenG

好吧，我想出了我自己的。我使用SQL驅動程序對使用ODBC驅動程序的相同確切代碼進行了代碼基準測試。

我的結果如下。

ODBC驅動程序：100％連接成功。平均持續時間796 毫秒。
SQL驅動程序：100％連接成功！平均持續時間 641毫秒。

ODBC驅動程序執行速度稍慢。我仍然可以使用，因爲這個基準再次是2萬條記錄，所以差異應該是非常小的。

謝謝大家的幫助！

Paul

來源

2011-07-15 21:28:24 Paul

我不能討論的表現，但你存儲連接字符串到數據庫中的一個配置文件？在我看來，更改連接機制是更改連接字符串以找到正確服務器的更復雜的解決方案。

來源

2011-07-15 13:30:22

它存儲在web.config文件中。每當我們部署時改變它並不是什麼大不了的事，但我們的團隊對我們的開發，QA和生產服務器的代碼有不同的限制。使用ODBC數據源修復了這個問題。這並不是一件非常困難的事情，實際上我已經做到了，我只是想知道是否有人知道在連接到SQLServer時是否存在使用odbc驅動程序而不是SQLServer驅動程序的缺點。 – Paul

通常，只有在創建到數據庫的連接時，性能下降纔會發生。該操作對於所有提供者類型是密集的。

有人請糾正我，如果我錯了，但從.NET4微軟已經創建了一個我認爲允許LINQ to SQL的Oracle驅動程序。我知道它在某一時刻正在工作，我知道Oracle驅動程序是針對.NET4的，所以我認爲它們是相同的。

但是，LINQ to Entities是db不可知的，所以只要你堅持，你應該沒問題。

來源

2011-07-15 13:32:18 Josh

使用odbc代替c中的sql服務器連接＃

回答

相關問題