切换到SharePoint List后端后MS Access主窗体与子窗体关联错位问题

该异常本质是Access对接SharePoint List作为后端时，主键生成逻辑和原生Access后端不一致导致的：原生Access后端的自动编号主键在新记录创建时就会本地生成并固定，而SharePoint List的主键ID需要等主记录成功提交到服务器后才会返回有效值，未提交的新主记录的ID是Access临时分配的占位值。如果用户未保存主窗体活动记录就直接在子窗体录入时长数据，后续主记录提交后ID发生变化，就会出现子记录关联错位，最终表现为子记录匹配到了创建时间更早的其他活动记录。

除了你已提及的方案外，还可以根据开发成本选择以下优化方案：

• 低改造成本方案：仅加少量VBA控制编辑权限
  不需要解除窗体绑定，在主窗体Current事件中加入判断：如果当前是新活动记录（Me.NewRecord = True），直接设置子窗体subVolTime.Enabled = False；在主窗体AfterUpdate事件中再恢复子窗体可编辑状态，强制用户必须先保存活动记录才能录入志愿者时长，几行代码即可完成改造，不改动现有绑定逻辑。
• 后端兜底方案：SharePoint端加校验约束
  直接在SharePoint的tblVolTime列表中为EventID字段添加验证规则，要求关联的tblEvents记录的创建时间必须早于当前tblVolTime记录的dateAdded，不符合规则的记录直接从后端层面拒绝写入，避免前端逻辑漏判导致异常数据入库。
• 根源性修复方案：自定义关联主键
  放弃用SharePoint自动生成的ID作为两表关联键，改用Access前端生成的GUID作为关联字段：新建活动记录时本地直接生成固定GUID写入主表关联字段，子记录新增时直接取该固定GUID作为EventID的值，不需要等待SharePoint返回主键，从根本上避免临时ID错位问题。
• 操作侧校验方案：子窗体插入前校验
  在子窗体BeforeInsert事件中添加校验逻辑，先查询确认当前主窗体的活动ID已经在SharePoint的tblEvents中存在，不存在则弹出提示要求先保存活动记录，直接阻断未关联有效活动的子记录录入。
• 历史数据修复：批量清理异常记录
  先运行审计查询导出所有dateAdded早于对应活动创建时间的tblVolTime记录，和业务人员核对后修正关联的EventID或删除无效记录，避免历史错误数据干扰正常业务使用。

内容的提问来源于stack exchange，提问作者T97