我正在将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