oracle 自用户启动更新过程以来，数据库中的当前数据版本已更改

Current version of data in database has changed since user initiated update process

提问by Bishan

I have a Master Detailform in my Oracle APEXapplication. When I am trying to update data in this form, I am getting below error.

我的Oracle APEX应用程序中有一个Master Detail表单。当我尝试以这种形式更新数据时，出现以下错误。

Current version of data in database has changed since user initiated update process. current row version identifier = "26D0923D8A5144D6F483C2B9815D07D3" application row version identifier = "1749BCD159359424E1EE00AC1C3E3FCB" (Row 1)

自用户启动更新过程以来，数据库中的当前数据版本已更改。当前行版本标识符 = "26D0923D8A5144D6F483C2B9815D07D3" 应用程序行版本标识符 = "1749BCD159359424E1EE00AC1C3E3FCB"（第 1 行）

I have cleared browser cache and try to update. But it not worked.

我已清除浏览器缓存并尝试更新。但它没有用。

How can I solve this?

我该如何解决这个问题？

回答by sangam

I have experienced similar problem where my detail records set has timestamp fields. By default master detail wizard creates the timestamp fields as date picker type fields. If you set the date format on these, it would resolve the issue.

我遇到过类似的问题，我的详细记录集有时间戳字段。默认情况下，主从向导将时间戳字段创建为日期选择器类型字段。如果您在这些上设置日期格式，它将解决问题。

回答by StewS2

This blog post tries to address this issue on a Tabular Form (I know that's not what the original issue was with, but thought it might be related). It says the same as @sangam does below.

这篇博文试图以表格形式解决这个问题（我知道这不是最初的问题，但认为它可能相关）。它说与@sangam 在下面所做的相同。

Short version: If you have an updated field that's timestamp datatype, you should set a date/time format.

简短版本：如果您有一个时间戳数据类型的更新字段，您应该设置日期/时间格式。

http://apexbyg.blogspot.com/2015/05/tabular-form-bug.html

http://apexbyg.blogspot.com/2015/05/tabular-form-b​​ug.html

My tabular form has a field that's timestamp datatype, but I had already set a date format, so this didn't help me.

我的表格表单有一个时间戳数据类型的字段，但我已经设置了日期格式，所以这对我没有帮助。

回答by StewS2

Here's another possibility, which I discovered was the case in my application.

这是另一种可能性，我在我的应用程序中发现了这种情况。

That would be if the data the original checksum was calculated on is truly different than the pre-update checksum calculation, due to a design-flaw in your query!

如果由于查询中的设计缺陷，计算原始校验和的数据与更新前的校验和计算确实不同！

In my application, the source for one of the updateable fields was COALESCE(name_calced, name_preferred). In the source table, the person's name could already be loaded in the record by an external process and we save it to one field - name_calced. But the end-user can enter a preferred name, which we wanted to save to the name_preferredfield. We wanted to initially populate the displayed, updateable tabular form field with name_calced, if one existed, or name_preferredif the user had already provided a preferred name. Then they could change that value and save it back to the database.

在我的应用程序中，可更新字段之一的来源是COALESCE(name_calced, name_preferred). 在源表中，人名可能已经被外部进程加载到记录中，我们将其保存到一个字段 - name_calced。但是最终用户可以输入我们希望将其保存到name_preferred字段的首选名称。我们希望最初使用name_calced填充显示的、可更新的表格表单字段（如果存在）或name_preferred如果用户已经提供了首选名称。然后他们可以更改该值并将其保存回数据库。

I finally discovered that the Save action threw the error message if name_calcedwas non-null, but name_preferredwas null. I realized that the initial checksum was calculated based on name_calced, but the pre-update checksum was based on name_preferred, so the application thought someone had changed the value in the background and showed the error message.

我终于发现，如果name_calced为非空，但name_preferred为空，则 Save 操作会抛出错误消息。我意识到初始校验和是基于name_calced计算的，但更新前校验和基于name_preferred，因此应用程序认为有人在后台更改了值并显示错误消息。

What I don't understandis how this problem didn't show up in the past 3 years the application has been running in production!

我不明白的是，在过去 3 年中，该应用程序在生产环境中运行时如何没有出现此问题！

My solutionis to make the field source only on name_preferred, which immediately solved this problem. I also think the back-end process will also get changed to pre-populate that table field from name_calced, so the user always sees the base value, if there is one.

我的解决方案是只在name_preferred上制作字段源，这立即解决了这个问题。我还认为后端进程也将更改为从name_calced预填充该表字段，因此用户始终会看到基值（如果有）。

回答by Mark Lindros

I just had this issue myself. Now, I realize that tabular forms are deprecated at this time, but I have an application that was developed beforehand and still uses them. This issue occurred and I had to get one of our big guns at Oracle to help me out. I do a lot of DB work and a decent amount of Apex development but I'm more of a Java, WebLogic, etc guy, and I really couldn't figure this one out.

我自己也有这个问题。现在，我意识到此时不推荐使用表格形式，但我有一个预先开发的应用程序并且仍在使用它们。出现了这个问题，我不得不让 Oracle 的一名大佬帮我解决这个问题。我做了很多数据库工作和相当数量的 Apex 开发，但我更喜欢 Java、WebLogic 等人，我真的无法弄清楚这一点。

In my case, it turned out to be really simple. One of the columns in my tabular form was a hidden field, generated via a sub query. Being hidden, this column is not editable by the user and should not be part of the MRU update. I had the field set to "Hidden Column (saves states)" and setting its type to "Hidden Column" fixed the issue. So, this leads to sub queries being executed in such a way as to change the checksum for the overall query before hitting submit (save), causing the error.

就我而言，结果证明它非常简单。我的表格形式中的一列是一个隐藏字段，通过子查询生成。由于隐藏，此列不能由用户编辑，不应成为 MRU 更新的一部分。我将该字段设置为“隐藏列（保存状态）”并将其类型设置为“隐藏列”解决了该问题。因此，这会导致子查询以这样一种方式执行，即在点击提交（保存）之前更改整个查询的校验和，从而导致错误。

For those who are continuing to troubleshoot this, look at your query for every field that you have specified and note which columns are editable in the tabular form. All other fields should be set in a way that makes them not save state so that they are not part of the update.

对于那些继续解决此问题的人，请查看针对您指定的每个字段的查询，并注意表格形式中哪些列是可编辑的。所有其他字段的设置方式应使它们不保存状态，因此它们不属于更新的一部分。

回答by EdHayes3

I had this error when I had two update processes processing on submit.

当我在提交时处理两个更新进程时，我遇到了这个错误。

My solution was to add a condition to both processing steps. I had forgotten to do this when I made an additional process for Button A, but I never updated Button B to limit it's behaviors.

我的解决方案是在两个处理步骤中都添加一个条件。当我为按钮 A 做一个额外的过程时，我忘记了这样做，但我从来没有更新按钮 B 来限制它的行为。

Navigation: Processing -> Processes -> [Your Process Name] -> Server-side Condition -> When Button Pressed = [Your button Name]

导航：Processing -> Processes -> [Your Process Name] -> Server-side Condition -> When Button Pressed = [Your button Name]

回答by Ralph177

In my case I had a column from a secondary table that was not set as Query Only and was being updated! The error would occur trying to save a column not in the table being updated. It took me half a day to figure it out (the column names were the same).

在我的情况下，我有一个辅助表中的列没有设置为仅查询并且正在更新！尝试保存不在正在更新的表中的列时会发生错误。搞了半天才弄明白（列名都一样）。

回答by Pankaj Singh

I have noticed this error comes when I was working Tabular Form and has disabled one of the form operations i.e. by setting server-side condition to "Never" for add, apply changes (submit) buttons

我注意到这个错误发生在我使用表格表单并禁用了表单操作之一，即通过将服务器端条件设置为“从不”以添加、应用更改（提交）按钮

When I have restored back to its original state, it worked as expected.

当我恢复到原始状态时，它按预期工作。

In case you have to hide Add/Update button, use some other option.

如果您必须隐藏添加/更新按钮，请使用其他选项。

https://compknowledgebase.blogspot.com/2018/12/oracle-apex-error-current-version-of.html

https://compknowledgebase.blogspot.com/2018/12/oracle-apex-error-current-version-of.html