Ms access Access如何使用存储在Sharepoint中的所有表运行查询，以及何时不运行？

问题是，在这些情况下，流程如何处理CPU和网络使用情况：

运行仅包含共享点列表的查询

是否将所有sql请求处理到Sharepoint Server

运行包含SharePointList和本地表的查询

在这种情况下，所有sharepoint列表都是在本地下载和处理的吗

---

谢谢你的帮助

那么，访问SharePoint的链接表总是使用相关数据的本地副本

您可以在退出时检查“清除”缓存，但出于性能原因，我不建议您这样做

所以access所做的是“首先”与数据的本地副本进行“同步”（请记住，在本文中，我不是在讨论本地访问表，而是仅在本文中讨论链接表）

这意味着sql查询实际上是在本地处理的，只会检查更新和“同步”本地表

在Access 2010（和SharePoint 2010）之前，这个“本地”缓存是原始xml，速度非常慢

现在，本地数据库引擎用于这种SQL。但是，高速本地索引仅适用于PK列–其他列（遗憾的是）没有索引。然而，由于本地处理和ram性能“愚蠢”快，因此对于多达50000条记录的表来说，这种方法非常有效

如果在链接的+“缓存”表和本地访问表之间进行连接？好的，如果您在链接表的PK列上加入，那么这个处理将发生“本地”。然而，如果你加入了PK之外的任何东西，那么你就没有索引——这会占用CPU和ram本地空间——这样的查询执行得不太好

因此，一般来说，用于“命中”链接表的任何SQL实际上都是针对本地缓存表“运行”本地的。如果本地链接表没有完整的数据缓存，则会向SharePoint发出请求。在这种情况下，数据的提取可以也将限于您的筛选器，但SharePoint数据是xml数据列表，而不是SQL server那样的行和列表。SharePoint在处理此类请求方面做得“不错”，但请记住，SQL不是在服务器端处理的（它被转换为camel语法，这是一种“web服务”拉动，而不是ODBC或真正的数据库拉动）

是的，数据是在本地下载和处理的。但是，如前所述，Access“保留”了本地数据的缓存。因此，从理论上讲，您可以查询一个20000行的表，并且几乎不会发生到SharePoint的任何网络流量（只有同步表的测试/检查）。如果没有发生表更改，那么这种查询将针对本地表缓存“主要”进行本地查询

请记住，这意味着这样的查询可以运行得相当快，但对大型表的更新仍然会运行得很慢，因为对于每一行本地更新，必须将该数据“同步”到SharePoint。而且，您不能像使用SQL server那样运行/使用服务器端更新。这里的原因很简单，因为如果您尝试在服务器端运行更新，那么每一行的同步都会发生在客户端，并且您仍然会受到巨大的网络惩罚

因此，在某些情况下，针对SharePoint的此类SQL需求将围绕SQL server运行。（因为可以使用本地表缓存）。由于从Access到SharePoint的通信是一种“web服务”，因此技术堆栈是围绕web的概念编写的，它允许连接中“经常”出现小的中断。事实上，如果您的连接100%丢失，则访问将继续对本地数据进行操作，直到您重新建立internet连接，并且SharePoint可能会“同步”本地表数据。因此，此设置允许“离线”模式–在连接断开的情况下，访问可以正常工作

如果您使用ODBC连接SQL server，则internet连接中的“任何”小中断都将中断连接，并且您通常必须退出并重新启动Access。因此，从“internet”的角度来看，SharePoint使用的技术堆栈远比SQL server好

但是，最大的问题是SharePoint列表对于具有大量行的应用程序或具有大量行更新的应用程序的伸缩性不好

还要记住，SharePoint上表之间的所有关系都必须具有pk ID（数字），并且FK也必须是数字。因此，支持SharePoint表之间的级联更新和级联删除，Access也支持这一功能

所以一般来说，我会将表的大小限制在10000行，或者15000行。请记住，如果使用office 365，则查询数据集限制为5000行。如果您正在运行现场SharePoint，则可以关闭所有这些“限制”和限制

因此，一次更新大量行的应用程序在访问SharePoint时无法正常工作。具有大量行和大量关系连接的应用程序也不能很好地扩展。请记住，我在这里提到的缩放有两种类型。在本例中，我们讨论的是大行数，而不是大量用户的“水平”缩放。SharePoint（和Access）可以处理相当大的用户数，但大的数据行数是另一回事

实际上，服务器端不会处理任何sql，因为SharePoint不会使用sql引擎更新行—它是一个基于web服务的更新系统

这实际上取决于行集的大小。对于预期低于10000行的应用程序，您应该很好。如果您希望行数更大，那么我建议您使用SQL server作为后端，如果您想要基于云的解决方案，甚至可以使用SQL Azure

编辑： 此外，要获得可接受的性能，您需要Access 2010或更高版本，以及sharePoint 2010或更高版本。尤恩