MS Access VBA故障停机时长校验异常：首次录入超限未被拦截

看起来你遇到的核心问题是Form_AfterUpdate事件的触发时机不对，再加上首次录入时的特殊场景（没有上一条记录），导致校验逻辑完全失效。我们来一步步修正这个问题：

问题根源分析 #

1. Form_AfterUpdate的滞后性：这个事件是在记录已经保存到数据库之后才触发的——也就是说，当你发现停机时长超限时，错误的记录已经被存入数据库了，这时候再删除不仅用户体验差，还可能因为DTSum的计算滞后（首次录入时累计值可能还没同步更新）导致判断不准确。
2. 首次录入的逻辑漏洞：原代码里的DoCmd.RunCommand acCmdRecordsGoToPrevious在首次录入时会直接报错，因为根本没有上一条记录，这会直接中断你的校验流程，导致拦截操作根本执行不了。

修正后的代码方案 #

改用Form_BeforeUpdate事件，在记录保存之前就进行校验，这样能直接拦截错误输入，无需事后删除记录：

Private Sub Form_BeforeUpdate(Cancel As Integer)
    ' 强制刷新计算控件，确保DTSum是最新的累计值
    Me.DTSum.Requery
    
    ' 用Nz函数避免空值导致的错误判断
    If Nz(Me.RunTime.Value, 0) < Nz(Me.DTSum, 0) Then
        MsgBox "You have too much downtime", vbExclamation, "Validation Error"
        ' 取消当前记录的保存操作，直接拦截错误
        Cancel = True
        ' 将焦点移回停机分钟数字段，方便用户修改
        Me.停机分钟数.SetFocus ' 这里替换成你表单中实际的停机分钟数字段名
    Else
        MsgBox "Okay", vbInformation
    End If
End Sub

关键改进点说明 #

• BeforeUpdate事件：在记录保存前触发，通过设置Cancel = True可以直接阻止错误记录被保存，从根源上解决问题，不用再事后删记录。
• Nz函数的使用：避免因为控件值为空（比如首次录入时RunTime未赋值的极端情况）导致的逻辑错误。
• 强制刷新计算控件：确保DTSum的累计值是实时更新的，不会因为计算控件的滞后更新导致校验结果不准。
• 移除无效跳转操作：不需要再执行删除记录和跳转的操作，直接取消保存并引导用户修改即可。

额外注意事项 #

1. 确保你的DTSum计算控件的控件源是正确的，比如应该是类似Sum([停机分钟数])这样的聚合计算，并且要确认它会随着每一次输入实时更新。
2. 如果你的表单是连续表单或数据表视图，可能需要调整计算逻辑，确保DTSum是针对当前所有已录入记录的累计值。

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