我有一个 SysOperation 框架进程,它创建一个 ReliableAsynchronous 批处理来发布装箱单,并且一次创建几个。
根据我单击创建它们的速度,我得到:
Cannot edit a record in LastValue (SysLastValue).
An update conflict occurred due to another user process deleting the record or changing one or more fields in the record.
和
Cannot create a record in LastValue (SysLastValue). User ID: t edit a, Class.
The record already exists.
在 BatchHistory 中有几个。我已经this.parmLoadFromSysLastValue(false);
定了。我不确定如何防止写入 SysLastValue 表。
知道会发生什么吗?
我也经常遇到这个异常,所以我养成了DuplicateKeyException
在服务操作中捕捉的习惯。当它被抛出时,抓住它并重试(默认为 5x)。当许多进程同时运行时会发生错误,就像你现在正在做的那样。
DupplicateKeyException
SysLastValue
可以在事务中捕获,因此如果可以找到代码,你可以通过在执行表中插入的代码周围放置 try/catch 来改进。
据我所知,这些是唯一出现在此表中插入记录的情况(可能在内核中除外):
InventUnusedDimCleanUp.serialize()
SysAutoSemaphore.autoSemaphore()
在那里放置一个断点并查看该代码是否被执行。如果是这样,你可以添加一个 try/catchretry
并查看是否“修复”它。
你还可以使用跟踪驾驶舱和跟踪解析器来确定该记录的插入位置,如果它不是这两者之一。
我关于 LoadFromSysLastValue 的理论:我相信设置this.parmLoadFromSysLastValue(false)
不起作用,因为它只在对话框启动时考虑,而不是在执行操作时考虑。批量时,不会使用 SysLastValue 来初始化你的数据合约,因为你希望它使用你在数据合约中提供的确切参数。
很棒的信息。我想我正在尝试追踪 SysOperationFramework 与 SysLastValue 交互的位置,但我最终将其归结为
formLetter.parmLoadFromSysLastValue(false);
我认为最终修复了它。我也一直在DuplicateKeyException
重试,但我认为范围错误。