切换到 Sharepoint 后端后，主窗体错误链接到子窗体 - MS Access

Question

为什么我的表单/子表单会使用 SharePoint 列表后端错误链接记录？

我有多年使用 MS Access 的经验，但这是我第一次使用 SharePoint 列表作为后端。

我为一家小型非营利组织开发了一个小型数据库。从位于一台用户计算机上的 Access 365 前端和后端开始。这在几个月内运行良好且正确，上个月我们将后端迁移到 SharePoint 列表，以便其他两个用户可以使用该数据库。他们每个人的桌面上都有前端。

有一个绑定表单，Events，链接到 tblEvents。此表单上的子表单 subVolTime 链接到 tblVolTime，以显示志愿者以及他们在活动中花费了多少时间。在 subform 属性中，Link Master Fields 设置为 tblEvents.ID；链接子字段设置为 tblVolTime.EventID。没有额外的 VBA 代码。

我们使用向导迁移到 SharePoint 列表，没有做任何其他事情。不久之后，我的用户注意到在事件中出现了错误的人。他只看名字就知道了。

我创建了一个审计查询，我可以看到在某些情况下，tblVolTime 中的 dateAdded（创建记录的日期）早于 tblEvent 中事件的 dateAdded。这不可能是正确的，因为您必须在 tblVolTime 中的关联记录之前在 tblEvent 中有一条记录。

例如，有一个事件 ID 261，创建于 2021 年 11 月 4 日。与此事件 ID 相关联的志愿者的记录创建于 2021 年 10 月 7 日。出现了问题。

欢迎提出任何建议。我的想法包括：取消绑定表单；隐藏子表单，直到事件记录被保存；在用户实际向其中添加任何数据之前创建事件记录。

Answer 1

嗯，很难说。但是，与将 Access 数据移动到 SQL 服务器不同？

将数据上移到 SharePoint 是一个非常不同的过程。为什么？

首先，当将数据移动到 SharePoint 时，您拥有的自动编号 PK（并且您必须为所有表格拥有）通常会重新编号。

现在，由于自动编号的重新编号？

嗯，这意味着在您迁移数据之前，您确实做得更好，但确实非常确定在这些表之间建立了关系。

在 Access 的情况下，虽然在大多数情况下我们确实建立了正确的关系，但老实说，您真的不必这样做。换句话说，如果我为子表单设置主链接和子链接？好吧，访问只会为主表生成 PK 自动编号，为子表生成 pk 自动编号。并且 THEN 在数据插入期间会将该子表中的“FK”值正确插入/设置到父表中。只要正确设置链接主/子设置（但没有设置实际关系），那么应用程序就会很高兴地工作。

如果要迁移数据说SQL server？好吧，由于在此上传过程中不会触及 PK 自动编号 - 那么所有关系及其数据也将有效地访问 SQL 服务器。

但是，对于 SharePoint？所有表格的自动编号现在并且将在大多数情况下重新生成！！！！

但是，如果您使用 Access 扩大数据的大小，这往往不是问题。它内置了 SharePoint 支持，如果父记录从 Access 上升到 sharepoint 并且 PK id 已更改？没有问题，因为如果您真的进行了设置，并且您确实进行了关系设置，那么迁移过程足够聪明，可以找到子记录并更新 FK 值。但当然，迁移过程只有在您了解关系的情况下才能发挥这种神奇作用。

另一个简单的例子？ 假设我们有一个简单的表单，并且我们有一个 SMIPLE 组合框来选择说喜欢的颜色。

tb颜色 ID（自动编号 PK）。 颜色（文字颜色）。

所以，现在我们有了一个简单的表单，我们放入了一个组合框。当我们从组合中选择“红色”或“蓝色”这样的简单颜色时，我们当然会保存上表中的“pk”id。

现在有很多像上面这样的简单表格，从未使用过，也没有为设置房地产而烦恼。 （不需要 - 只需从组合框中选择几个）。

如果你将数据放大到 sql server 呢？同样，这可以正常工作 - 完全没有问题。

但是，如果您升级到 SharePoint？即使是为这个简单的愚蠢的小组合框，您也确实但最好建立关系。同样，原因很简单。当那个简单的选择列表值升至SharePoint时，Autonumber PK ID将会更改。因此对于使用该简单选择列表的任何其他表？您已经并且必须在您的关系窗口中设置这实际上是关系 - 再一次，原因是自动编号的重新编号。

那么对于任何使用 PK 和 FK 值的关系？在使用 SharePoint 时，必须在所有情况下都必须在传输数据之前在访问数据表（关系窗口）中定义它们。再说一次，原因很简单 - 在上传到 SharePoint 的过程中，自动编号会改变！！！并且由于它们发生了变化，因此使用这些 PK 值（作为 FK）的任何其他依赖表必须是已定义关系的一部分。如果在迁移到 SharePoint 之前未定义它们，则 PK 值的更改不会告诉 SharePoint 去查找并正确更新所有“子”记录或所谓的 FK 值。

那么，第一个要问的问题是，相关数字的中断是很久以前（在迁移时）发生的，还是由于一些错误的代码或选择了错误的值而发生的？

因此，将相关数据迁移到 SharePoint 是一项“微妙”的操作，主要原因当然是在您迁移之前，相关表已被设置为强制关系。如果这种关系没有严格定义，那么在迁移过程中，基于这些 PK/FK 值的数据关系将在迁移时中断。

现在，这个有问题的子表单没有正确的链接主/子设置可能是一个简单的问题 - 这是首先要检查的事情。