嗯，使用Azure比运行连接到SQL服务器的本地实例的Access慢的原因是因为，慢得慢！

我的意思是，如果你要旅行30英里，你可以选择步行或开车。

所以这是你需要知道的问题：

为什么走路比开车慢？

回答，因为你的旅行速度较慢！

那么为什么使用Azure在本地计算机或本地网络上运行的SQL服务器实例更慢？

答案：因为与Azure的连接速度大约慢100倍！

这里的想法是你不会考虑连接速度的差异是这里的问题。阅读公众可能会认为这样的设置（在PC上的访问前端到SQL服务器的Azure实例）不是一个可行的设置。

所以这里的第一个问题是记下你与后端数据库的连接速度。

典型的办公室局域网速度为100mbits，或者今天大多数都是1gig - 即使您在百思买购买的el-cheapo路由器现在的额定速度为1gig（1000 mbits）。

但是，您的典型高速互联网的额定值约为5或10兆位。所以这慢了100倍。（实际上1000/5 =慢200倍!!!）。

这意味着如果使用Access和SQL服务器，您的办公室网络上的NOW需要3秒钟吗？那么一个WAN（通过互联网），然后你需要通过改变你的连接速度多次（这是如此简单 - 但它似乎逃脱所有！）。所以，如果幸运的话，你的互联网可能有5兆位的速度等级。这意味着你去了

1000/5 = 200

你现在拿200和多你现有的延迟说3秒就得600秒（如果你想知道那就是10分钟！）。所以你从3秒钟到10分钟！

这种速度比较就像走进体育用品商店购买橡皮船穿越大西洋。因此，不考虑互联网速度的变化，并想知道为什么事情进展缓慢是问题。

您当然可以使用Access Azure，但您必须实现两个简单的概念。

1 - 使用比LAN快50-200倍的连接进行连接和测试，测试运行速度要慢50到200倍！在WAN的速度连接中，与WAN相比，未能提及并考虑到MASSIVE DIFFERENCE是一个简单的问题。

2 - 打开绑定到大型数据表的表单将导致案例性能问题。

我坐在公共汽车站跟一位90岁的奶奶女士说话。我问过她：

你有没有用过即时出纳员？她说，为什么是的，我一直都在使用它们。

我在这里问到，你不觉得让你的柜员机在你等待的时候下载所有的人民帐户，然后问你的账号是不是很糟糕？

老太太当然说，那太傻了。我输入了我的帐户密码，机器只会下载我的帐户信息 - 这很实用且很明显。

换句话说，老太太意识到在用户输入或做任何事情之前下载大量数据是浪费带宽。

因此，您永远不想启动绑定到表格的表单，然后询问用户要处理的记录。为什么Access会将大量记录下载到表单中，然后询问用户或允许用户导航到所需的记录？

即使使用Google，它也不会将整个互联网下载到您的网页浏览器页面中，然后您可以通过ctrl-f搜索该网页的内容。

相同的概念应该应用于Access应用程序。一个设计，询问要处理什么，然后启动一个绑定到表格的表单，其中＆＃34;其中＆＃34;因此，条款将解决这个问题。

因此，如果您有一个显示客户发票的表单（甚至是子表单），您将首先询问发票号，然后使用将表单限制为ONE发票的where子句启动该表单！

请记住，您仍然可以使用绑定到100万行表格的发票表单，并且只有一条记录将被拉下网络连接 *如果一个人使用“where”子句

因此，典型的互联网连接具有足够的速度来运行浏览器，并且还具有足够的带宽速度来拉下一些记录。访问通常会因糟糕的性能而受到不好的影响，但这只是因为访问开发人员而忽略了明显的建议，即将大量不需要的东西下载到表单中会很慢。

因此，基于Web的应用程序，甚至用vb.net编写的桌面应用程序都可以很好地运行云中运行的SQL Azure，因为这些应用程序不会启动绑定到大型数据集的表单而不会仅仅允许用户请求他们需要查看和查看的内容。

对于Access和使用SharePoint？这种设置非常快，实际上比SQL Azure，MySQL或任何传统数据库系统快得多，因为当您使用SharePoint表和Access时，Access会自动同步本地数据的副本。此设置意味着您的应用程序将继续运行，无需任何互联网连接。恢复连接的瞬间，数据同步可以恢复。

这意味着，如果您有一个包含15,000行的表并运行该数据的报告，则报告可以在SharePoint后端运行并立即启动，因为所有时间前端都存在本地数据副本！所以这个设置非常适合离线模式，或者你有一个很慢和很慢的互联网连接，因为你注意到总是有本地数据副本 - 只有当记录被更改时才会发生同步，并且同步可以独立于Access发生。所以你改变了一条记录 - 它开始与SharePoint同步。

然而，对于必须更新的较大数据集，则SQL服务器要好得多，因为您可以在10,000行上执行sql更新，并且在使用SQL服务器时需要进行ZERO网络流量和数据传输以更新这10,000行（传递查询）并且在使用SharePoint时，10,000行将通过网络传输，因为本地副本需要更新行。因此，对于必须更新大量行或执行大量行更新类型的数据处理的应用程序，不存在将SharePoint用于数据库后端的巨大优势。

所以关键概念并带走：

您拥有的高速互联网连接通常比典型的廉价办公室（本地）网络慢10-200倍。这意味着2秒钟的操作现在需要10-200倍。

需要优化Access应用程序，以避免将太多记录加载到表单中。因此，建立搜索表单等首先要求用户提供他们需要处理的工作是所有优秀开发人员的基本而简单的要求，包括Access开发人员。

Access和SharePoint可能是最佳选择，这样的设置允许应用程序运行，甚至根本没有互联网连接。如果表格大小低于10,000行，则此设置通常是理想的。但是，对于必须更新大量行和数据处理繁重应用程序的应用程序，此设置很差，因为对任何行的更新都将通过网络进行案例数据同步。此设置也是最便宜的，因为具有SharePoint支持Access的单个Office 365帐户可以每月6美元，而这个6美元的帐户允许最多500个免费用户，这500个用户甚至可以使用他们的Gmail或非Microsoft帐户对于此设置。这样的访问应用程序适合在SharePoint表的范围内，往往需要更少的更改和优化，然后通过Internet使用SQL服务器。

使用SQL Server，使用视图，传递严格的查询，在某些情况下，编写存储过程允许更新和代码在不使用任何带宽的情况下运行。因此，可以向服务器发送单个更新查询，以更新10,000行数据 - 唯一的网络成本将是发送该sql语句的“微小”带宽量。

因此，虽然绑定表单可以与在云中运行的SQL Azure一起使用，但是需要构建类似于网络的软件，或者vb.net，在这些软件中，他们首先要求用户使用哪个帐户或客户进行处理。启动UI以显示给定数据。

因此，在访问权限中，您可以构建一个搜索表单，如下所示：

所以在一天结束时，重要的是忽略这里的帖子，这些帖子暗示在云中访问SQL是不可行的。使用适当设计的访问将比在Azure上运行的SQL服务器的典型Internet连接上工作得更好。

事实上，我看到有人在56k调制解调器上使用Access to SQL！

必须采用合理的设计，其中针对给定任务提取的数据受到限制 - 这是所有开发人员的标志 - 唯一的问题是Access不强制执行此方法，而大多数其他开发人员工具不允许您把你自己的东西挂在大桌子上！并不是Access很慢，但是当您做出糟糕的设计决策时，Access会很慢。

访问SharePoint可能是一个真正的赢家 - 特别是对于带宽不足，带宽不稳定甚至连接丢失，如果您运行相同的应用程序，应用程序将继续运行并运行速度超过99％的情况SQL后端。这里有一个很大的警告，因为只有某些类型的应用程序才能与SharePoint表一起使用。对于我来说，为什么，如何以及何时更好地应用这些应用程序超出了这里的简单帖子，但只需要知道SharePoint可以是令人难以置信的解决方案，但不是所有应用程序和SQL服务器都可以并且将是更好的选择。此SharePoint“更好”的选择只能根据给定类型的应用程序的个案评估来确定。

问题只是 Azure SQL数据库与小型 DTU（数据库事务处理单元）的运行速度不是很快，而是与SQL的内部实例相比服务器甚至托管在一个温和的现代服务器上。

我也检查了它，它需要非常仔细地设计查询和过滤 - 远离你通常可以逃脱的 - 以获得可接受的整体速度。另一方面，这是一种给予体验，将重点放在您可能为时已晚之前不会遇到的潜在瓶颈上。

好的，所以经过将近一周的努力才能让它工作（在Azure上访问前端到SQL Server后端），我得出的结论是它不可行溶液

我已经尝试过SQL Server，并在Azure上设置了Sharepoint 2016服务器，但也失败了。

有效的方法是使用Bullzipp的产品MS Access to MySQL转换访问表，然后在服务器上添加MySQL DB并导入Bullzip生成的文件。这里唯一需要注意的是Bullzip不喜欢较新的访问格式（它想要一个MDB文件），所以转到Access，创建一个新的空文件，但要确保将其文件类型设置为MDB。然后导入你的表并运行Bullzip。

它现在比SQL Server快得多，但我在Access中遇到了一些写冲突，所以我只需要通过代码并做我需要的任何事情，这样我就可以避免那些消息。

访问连接到Azure SQL Server后端的本地前端非常慢

3 个答案:

1 - 使用比LAN快50-200倍的连接进行连接和测试，测试运行速度要慢50到200倍！在WAN的速度连接中，与WAN相比，未能提及并考虑到MASSIVE DIFFERENCE是一个简单的问题。

2 - 打开绑定到大型数据表的表单将导致案例性能问题。