我正在將MS Access 2003應用程序升遷到SQL Server後端。在我的開發機器上，SQL Server是本地的，所以性能非常好。我想用遠程SQL Server測試性能，以便在重新設計應用程序時考慮網絡延遲的影響。我預計，現在看起來很快的一些查詢在部署到產品後將運行緩慢。如何在我的開發人員機器上模擬網絡延遲？
我怎麼能慢下來（或模擬遙控器的速度）的SQL Server不使用虛擬機，或搬遷SQL到另一臺計算機？是否有某種代理或Windows實用程序會爲我執行此操作？
感謝您的鏈接。 – 2010-11-14 00:42:32
您可能會誤解。 MS-Access支持所謂的「異類聯接」（即來自各種後端的表可以被包括在相同的查詢中，例如結合來自Oracle和SQLServer以及Access和Excel電子表格的數據）。爲了支持此功能，Access在客戶端上應用WHERE子句過濾器，但在智能後端存在「傳遞」查詢的情況下除外。在SQL Server中，篩選發生在服務器上運行的引擎中，所以SQL Server通常會將更小的數據集發送到客戶端。
的回答你的問題也取決於你的意思是「遠程」的東西。如果你坑在同一網絡上相互Access和SQL Server，該服務器上運行的SQL Server將消耗只訪問確實帶寬的一小部分，如果訪問MDB文件駐留在文件服務器上。 （當然，如果MDB駐留在本地PC上，則不會消耗網絡帶寬。）如果您通過雲將LAN上的Access與SQL Server上的Access進行比較，則比較標稱100 mbit/sec管道DSL或電纜帶寬，也就是說，高速電纜的標稱值可能爲20 mbit/sec，最多爲帶寬的五分之一，可能要低得多。
所以，你必須要更具體的瞭解你想比較有什麼。
你的本地PC消費的Access MDB駐留在文件服務器上對一些其他類型的客戶端從同一網絡上的駐留其他服務器上的SQL服務器消耗數據的比較上Access客戶端？你打算繼續使用Access作爲客戶端嗎？您的查詢是否會傳遞？
@Time：您的第一段不正確。在沒有使用特定於Access的關鍵字的情況下，SQL Server上的非直通查詢的WHERE子句正在SQL Server上運行。您的第二段也不正確：對於從Access對SQL Server運行的查詢，只有在JOIN和WHERE子句可以在SQL Server上運行的情況下才會消耗更少的帶寬，因爲沒有Access =特定的關鍵字，像'IIF'。如果存在特定於Access的關鍵字，則整個數據集將被下拉到Access，以便它可以在那裏運行關鍵字。 – RedFilter 2010-11-14 13:34:28
完整數據集是否被拉下取決於使用Access特定功能的位置。在SELECT子句中，沒有太大的問題，因爲所有WHERE標準和JOIN都將在服務器上執行，然後在SELECT中處理的函數僅在過濾的結果集上處理。但是，如果您在WHERE或JOIN子句或ORDER BY中使用特定於Access的函數，則可能會也可能不會拉下整個表 - 取決於Jet/ACE是否可以通過圖形的方式在Access之前分離出某些限制因素特定的功能。 – 2010-11-14 23:33:31
@大衛：是的，這是重要的一點。 – RedFilter 2010-11-16 15:19:55
有一個用於Windows，做那個（模擬低帶寬，延遲和必要時的損失）的軟件應用程序。雖然它不是免費的。試用版具有30秒的仿真限制。這裏是該產品的主頁：http://softperfect.com/products/connectionemulator/
@RedFilter：你應該指出你使用的是哪個版本的Access。 2006年的這份文件顯示，Access的帶子到客戶端的故事要比查詢是否包含「特定於訪問的關鍵字」更爲複雜。
http://msdn.microsoft.com/en-us/library/bb188204(SQL.90).aspx
但訪問可能會越說越有關使用服務器資源，每個新版本更復雜。
，我會堅持我簡單的建議：如果你想減少帶寬消耗，同時仍然使用Access作爲GUI，傳遞查詢做到最好，因爲這時它就是你的，不是接入，誰將控制線路上的數據量。
我仍然認爲你最初的問題/方法是錯誤的：如果你的Access MDB文件位於局域網上（是嗎？），你不需要模擬網絡延遲的影響。您需要嗅探Access生成的SQL語句，而不是引入一些任意且持續的「網絡延遲」因素。要將使用位於局域網服務器上的MDB的Access GUI與針對SQL Server後端的升遷Access GUI進行比較，您需要評估通過線路從後端服務器向客戶端下線的數據。除非使用傳遞查詢，否則即使「升級」訪問也可能會成爲帶寬低谷。但是，對於SQL-Server後端而言，正確編寫的客戶端與網絡帶寬相比，對於位於局域網服務器上的MDB進行反向訪問時總是會更加節省，其他條款。
當前訪問後端MDB位於LAN上。我目前正在嗅探查詢。 Access的版本是2003年。您理解的是，傳遞查詢是隻讀的，此外，我的一些查詢需要輸入參數。我的觀點是，確定哪些瓶頸應該得到解決的最快捷方式是憑經驗做到這一點。 – RedFilter 2010-11-16 15:18:12
只需編寫您的應用程序即可高效地進行數據檢索，即不會檢索超過用戶需求或可以同時使用的應用程序。這在任何環境下都是有效的，包括使用Jet/ACE後端。這沒有什麼魔力。您可能遇到邊緣情況的唯一情況是如果您計劃在開放式Internet上運行，並且帶寬相對較低（與LAN相比）。在這種情況下，你可能會做更多的事情，但我會建議不要過早優化 - 使其效率更高，然後修復不夠快的問題。 – 2010-11-13 21:20:48
@David：我正在移植一個非常大的現有MS ACcess應用程序。我需要對我做出的更改具有戰略性，沒有時間或預算來修改每個查詢和數據源。 – RedFilter 2010-11-13 23:25:17
我甚至沒有開始建議修改所有內容。如果它是一個設計良好的Access應用程序，它可能會表現得很好。如果不是，那將需要很多工作。無論後端是Jet/ACE還是服務器數據庫，只檢索有限數量的記錄的原則都可以實現快速高效的應用程序。 – 2010-11-14 23:30:35