从业务服务更新字段时出现错误 ORA-01407
我正在尝试使用业务服务更新 BC 字段的值。在执行它时，我收到以下错误：
ORA-01407: cannot update ("SIEBEL".""."MODIFICATION_NUM") to NULL.
由于修改编号是一个系统字段，因此我什至没有机会触摸该特定列。无法理解为什么会出现这个错误。
I'm trying to update the value of a BC field using a Business Service. While executing it I get the following error:
ORA-01407: cannot update ("SIEBEL".""."MODIFICATION_NUM") to NULL.
Since the Modification Num is a system field there is no chance that I would even touch that particular column. Not able to understand why this error is coming.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
我认为这里可能是您的服务写入记录正在调用有条件运行的业务组件上的代码，然后本身从业务组件代码中强制写入记录。这可以在业务组件代码中显式完成，也可以通过脚本与组件交互的某些方式隐式完成。一旦发生这种情况，那么尝试将修改号增加 1 的服务写入记录将无法执行此操作，因为此修改号是由可能的 BC 代码增加的，并且您会收到此错误。为了解决这个问题，我会检查有问题的 BC 并注释掉 PreSetFieldValue、SetFieldValue、PreWriteRecord 等事件的代码，并在初始测试中查看错误是否仍然发生。然后您需要隔离导致错误的 BC 代码部分。
I think what is likely here is that your Service Write Record is invoking code on the Business Component that is running conditionally and then itself forcing a Write Record from the Business Component code. This could be done either explicitly on within the Business Component code or be done implicitly by some of the manner ways that script can interact with a component. Once this happens then the Service Write Record which is trying to increment the Modification Number by one can then will be unable to do so as this Modification Number is incremented by possible BC code and you get this error. To resolve I would check out the offending BC and comment out code on events like PreSetFieldValue, SetFieldValue, PreWriteRecord and the like and see if the error still occurs as an initial test. Then you will need to isolate the part of the BC code which is causing the error.
您必须发布您尝试运行的更新语句，因为 ora 错误是专门的当列属性将列明确定义为不允许其中包含空值时，尝试将列值更新为空。
You'll have to post the update statement you attempted to run, because the ora error is specifically for attempting to update a column value to be null when the column attribute defines the column as specifically not allowing null values in it.
如果您查看 MODIFICATION_NUM，每次保存记录时它总是会增加 1。我相信这就是 Siebel 检测其他用户是否修改了记录的方式。您可以尝试以下操作：开始更新记录，但先不要保存。从不同的计算机或单独的浏览器窗口以不同的用户身份登录，更新完全相同的记录，然后保存。现在返回到第一个用户并尝试保存记录。您会收到一条错误消息。
无论如何，如果您创建新记录，请将 MODIFICATION_NUM 设置为 0。如果您更新记录，请将 MODIFICATION_NUM 增加 1。
不过，一般来说，建议使用 EIM 或其他官方支持的方式（例如 Java Data Bean）更新 Siebel 记录。
If you look at the MODIFICATION_NUM it will always increase by one each time the record is saved. I believe this is how Siebel detects if another user has modified the record. You can try this: Start updating a record, but don't save it yet. Log in as a different user from a different computer or just a separate browser window and update the exact same record, and save it. Now go back to the first user and try to save the record. You'll get an error message.
Anyways, if you create a new record, set MODIFICATION_NUM to 0. If you update a record, increase MODIFICATION_NUM by 1.
In general it would be advisable, though, to either use EIM or other officially supported means (Java Data Bean for instance) to update Siebel records.
请检查您正在使用的用户 ID。通常，如果该 id 的数据库未提供写访问权限，则可能会用 null 更新modification_num
Please check the user id that you are using ..usually if the write access isn't given for at the DB that id ..it might update modification_num with null
很可能您的代码中有错误（您必须在此处发布示例以获得任何帮助！），相关 Siebel 对象的配置中存在一些混乱（检查底层 BC 以查看是否有人添加了导致错误的配置或代码），或者这是 Siebel 中的已知错误（在 Siebel SupportWeb 上搜索）。
Chances are that either you have a mistake in your code (you must post a sample here to get any help with it!), there is something messed up in the configuration of the relevant Siebel Objects (check the underlying BC to see if someone has added config or code that causes the error), or this is a known bug in Siebel (search on Siebel SupportWeb).
第一步是找到试图清除您的模组号的总线补偿。为此，您必须找到正在更新 mod 编号的 SQL（它将是错误出现之前的那个 SQL），然后找到运行该 SQL 的总线comp（从 SQL 之前的 ObjMgrSqlObjLog 日志条目）。将 ObjMgrSqlLog 和 ObjMgrSqlObjLog 事件都设置为 4 并重现您的错误，这应该会为您提供所需的内容。
接下来，在buscomp 上查找映射到MODIFICATION_NUM 列的一个或多个字段。
最后，找出清除该字段的原因并修复它。可能是脚本、集成点、工作流程、buscomp 用户道具等......
祝你好运。
The first step is to find the buscomp that's attempting to blank out your mod number. To do that you'll have to find the SQL that's updating the mod number (it'll be the one immediately before your error appears) and then find the buscomp running that SQL (from a ObjMgrSqlObjLog log entry immediately before the SQL). Turn both ObjMgrSqlLog and ObjMgrSqlObjLog events to 4 and reproduce your error, and that should give you what you're looking for.
Next, find the field (or fields) on the buscomp that's mapped to the MODIFICATION_NUM column.
Last, figure out what's clearing that field and fix it. Could be a script, integration point, workflow process, buscomp user prop, etc...
Good luck.
一个好的猜测是，您已将自定义字段映射到 MODIFICATION_NUM（您永远不应该这样做），并通过代码或在 UI 中使该字段处于活动状态。检查您的 BC 是否使用了 MODIFICATION_NUM 列。
A good guess is that you've mapped a custom field to MODIFICATION_NUM (which you should never do) and made this field active, either by code or in the UI. Check your BC for use of the MODIFICATION_NUM column.
请检查有问题的 BC 是否有一个映射到 revision_num 列的字段（系统列永远不应添加到自定义字段），或者检查写入记录事件本身是否正在调用显式保存记录的自定义服务，这应该引发不同的错误之类的“您尝试修改的记录已被修改”
Please check if the BC in question has a field mapped to modification_num column ( system column should never be added to custom fields) , or check if write record event itself is invoking a custom service that explicitly saves the record, which should throw a different error of the likes of "the record you are trying to modify has already been modified"
您可能在同一个函数或方法中使用 WriteRecord() 两次。您可以检查一下吗？
此致。
Probably you are using WriteRecord() two times in the same function or method. Can you please check it ?
Best Regards.