我一直在使用Access来快速 Build 数据库原型 . 现在我想做一个小组在线测试，所以我拆分数据库并将后端放在Azure SQL Server上，然后重新链接 . 这是非常缓慢的，我一直在研究解决方案几天没有积极的结果 . 我的本地环境是Win10，Office2016 64位，互联网连接快速稳定 .
我尝试了不同的ODBC驱动程序，包括SQL Native Client v11 .
我已禁用NIC上的自动调整级别 .
我已经从服务器上的访问重新创建了所有查询 .
我确保在ODBC中跟踪已关闭 .
但我暂时启用了跟踪以查看发生了什么 . 如果我打开前端，登录（小用户表），并在第一个表单上做了一些事情（添加1条记录，包含3个子记录......真的......根本没什么花哨或重的，这只需要1分钟）然后关闭数据库，我看到跟踪日志文件是1.5MB .
所以我创建了一个空的Access文件和一个只链接到User表的ODBC链接（12列，20条记录），然后再次监视跟踪日志文件 . 打开访问权限不会向日志文件添加任何内容，但打开此链接表会使日志文件增长到255kb . 在访问中打开此表需要5秒钟 .
Access向服务器发送了大约800个请求，只打开这个小表 . 如果我将所有用户表数据粘贴到文本文件中，它只有2kb . 那为什么这么慢？
有关此问题的任何想法，特别是其他建议，以使这项工作更快？
亲切的问候，
3 回答
那么，使用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服务器，现在需要3秒钟？那么一个WAN（通过互联网），然后你需要通过改变你的连接速度多倍的时间（这是如此简单 - 但它似乎逃脱所有！） . 所以，如果幸运的话，你的互联网可能有5兆位的速度等级 . 那意味着你走了
1000/5 = 200
你现在拿200和多你现有的延迟说3秒，你得到600秒（如果你想知道那就是10分钟！） . 所以你从3秒到10分钟！
这种速度比较就像走进体育用品商店购买橡皮船穿越大西洋 . 因此，不考虑互联网速度的变化，并想知道为什么事情进展缓慢是这里的问题 .
您当然可以使用Access Azure，但您必须实现两个简单的概念 .
1 - 连接和测试的连接速度比局域网慢50-200倍，测试运行速度要慢50到200倍！在WAN的速度连接中，与WAN相比，未能提及并考虑到MASSIVE DIFFERENCE是一个简单的问题 .
2 - 打开绑定到大型数据表的表单将导致案例性能问题 .
我坐在公共汽车站跟一位90岁的奶奶女士说话 . 我告诉她以下事项：
你有没有用过即时出纳员？她说，为什么是的，我一直都在使用它们 .
然后我在这里问你不觉得让你的柜员机在你等待的时候下载所有的人民帐户然后问你的账号是不是很糟糕？
老太太当然说，这很傻 . 我输入了我的帐户密码，机器只会下载我的帐户信息 - 这很实用且很明显 .
换句话说，老太太意识到在用户输入或做任何事情之前下载一堆数据是浪费带宽 .
因此，您永远不想启动绑定到表的表单，然后询问用户要处理的记录 . 为什么Access会将大量记录下载到表单中，然后询问用户或允许用户导航到要求记录？
即使使用谷歌，它也不会将整个互联网下载到您的网页浏览器页面，然后您可以通过ctrl-f搜索该网页的内容 .
应该将相同的概念应用于Access应用程序 . 要求处理什么的设计然后启动绑定到具有“where”子句的表的表单将因此解决此问题 .
因此，如果您有一个显示客户发票的表单（甚至是子表单），您将首先询问发票号，然后使用将表单限制为ONE发票的where子句启动该表单！
请记住，您仍然可以使用绑定到100万行表的发票表单，并且只有一条记录将被拉下网络连接 *if 一个使用“where”子句 .
因此，典型的互联网连接具有足够的速度来运行浏览器，并且还具有足够的带宽速度来拉下一些记录 . 访问通常会因糟糕的性能而受到不好的影响，但这只是因为访问开发人员而忽略了明显的建议，即将大量不需要的内容下载到表单中会很慢 .
因此，基于Web的应用程序，甚至是用vb.net编写的桌面应用程序，可以很好地运行在 Cloud 端运行的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应用程序以避免将过多记录加载到表单中 . 因此， Build 搜索表单等首先询问用户他们需要工作的内容是所有优秀开发人员的基本而简单的要求，其中包括Access开发人员 .
Access和SharePoint可能是最佳选择，这样的设置允许应用程序运行，甚至根本没有互联网连接 . 如果表格大小低于10,000行，则此设置通常是理想的 . 但是，对于必须更新大量行和数据处理繁重应用程序的应用程序，此设置很差，因为对任何行的更新都将通过网络进行大小写数据同步 . 此设置也是最便宜的，因为具有SharePoint支持Access的单个Office 365帐户可以每月6美元，而这个6美元的帐户允许最多500个免费用户，这500个用户甚至可以使用他们的Gmail或非Microsoft帐户这个设置 . 这样的访问应用程序适合在SharePoint表的范围内，往往需要更少的更改和优化，然后通过Internet使用SQL服务器 .
使用SQL服务器，使用视图，传递严格的查询，在某些情况下，写入存储过程允许更新和代码在不使用任何带宽的情况下运行 . 因此，可以向服务器发送单个更新查询，以更新10,000行数据 - 唯一的网络成本将是发送该sql语句的“微小”带宽量 .
因此，虽然绑定表单可以与在 Cloud 中运行的SQL Azure一起使用，但是需要构建类似于Web的软件，或者vb.net，在这些软件中，他们首先要求用户使用哪个帐户或客户，然后启动UI显示给定的数据 .
因此，在访问中，您构建一个类似的搜索表单这个：
所以在一天结束时，重要的是忽略这里的帖子，这些帖子暗示在 Cloud 中访问SQL是不可行的 . 使用适当设计的访问将比在Azure上运行的SQL服务器的典型Internet连接上工作得更好 .
事实上，我看到有人在56k调制解调器上使用Access to SQL！
必须采用合理的设计，其中针对给定任务提取的数据受到限制 - 这是所有开发人员的标志 - 唯一的问题是Access不强制执行此方法，而大多数其他开发人员工具不会让您自己挂起像大表格的约束形式！这不是Access很慢，但是当您做出糟糕的设计决策时，Access会很慢 .
访问SharePoint可能是一个真正的赢家 - 特别是对于带宽不足，带宽不稳定甚至连接丢失，如果您使用SQL运行相同的应用程序，应用程序将继续运行并运行速度超过99％的情况结束 . 这里有一个很大的警告，因为只有某些类型的应用程序才能与SharePoint表一起使用 . 对于我来说，为什么，如何以及何时更好地应用这些应用程序超出了这里的简单帖子，但是只需要知道SharePoint可以是令人难以置信的解决方案，但不是所有应用程序和SQL服务器都可以并且将是更好的选择 . 此SharePoint“更好”选择只能在对所讨论的给定类型的应用程序进行逐案评估时确定 .
问题只是Azure SQL数据库与小型DTU（数据库事务单元）的运行速度不是很快，相比之下，即使是在中等规模的现代服务器上托管的SQL Server内部实例也是如此 .
我也检查了它，它需要非常仔细的查询和过滤设计 - 远离你通常可以逃脱的 - 以获得可接受的整体速度 . 另一方面，这是一种给予体验，将重点放在您可能为时已晚之前不会遇到的潜在瓶颈上 .
好的，所以经过将近一周的努力才能让它工作（在Azure上访问前端到SQL Server的后端），我得出的结论是，这不是一个可行的解决方案 .
我已经尝试过SQL Server，并在Azure上设置了Sharepoint 2016服务器，但也失败了 .
有效的方法是使用Bullzipp的产品MS Access to MySQL转换访问表，然后在服务器上添加MySQL DB并导入Bullzip生成的文件 . 这里唯一要注意的是Bullzip不喜欢较新的访问格式（它想要一个MDB文件），所以转到Access，创建一个新的空文件，但要确保将其文件类型设置为MDB . 然后导入你的表并运行Bullzip .
它现在比SQL Server快得多，但我在Access中遇到了一些写冲突，所以我只需要完成代码并做我需要的任何事情，这样我就可以避免这些消息了 .