Ibm midrange AS/400：为什么DB2表更改不会在整个系统中立即生效？

我遇到了一个问题，我在后端更新了AS/400-db2中的一个表，但是更改没有通过前端反映出来

我们有一个名为“SH.PROM”的表格，用于指定每月促销的日期范围。我已经用正确的压缩和分区小数和EBCDIC字符更新了“SH.PROM”。但是，当其他人尝试输入折扣商品时，折扣不会显示在前端

---

是否有命令调用系统范围的更新，以便更改立即生效？

假设您正在使用RPG程序更新表。 让我们进一步假设RPG程序将SH.PROM声明为不带密钥的更新主文件。 在这种情况下，RPG（为了效率）将缓冲数据库操作，将更新的行存储在内部缓冲区中，直到程序结束并将缓冲区刷新到磁盘。如果是这种情况，则在RPG编译器列表的底部会有一条消息，表明正在使用阻塞。在这种情况下，一个程序可以更新一个表，但数据库还不知道更新的行

如果您在提交控制下操作，则会出现一种稍有不同的情况，但如果我们假设一行已锁定以进行更新，但尚未提交，则其他作业将保持该锁定。他们不会看到旧数据，而是根本无法读取未提交的更改，最终会得到记录等待超时

还有一种情况是，您在SH.PROM上构建了一个逻辑文件，它是MAINT（*REBLD）。更新SH.PROM；最终用户阅读SH.PROML1，需要一些时间来重建索引，然后才能看到记录

除此之外，真的没有办法延迟或推迟数据库更新。一般来说，如果您更新一行，它将立即可用。上述情景似乎都没有反映您正在报告的内容。检查以确保更新的表与用户访问的表相同。您可能正在更新TESTLIB/SH.PROM，而用户正在读取PRODLIB/SH.PROM。或者，可能有一些夜间进程将SH.PROM传播到其他表中，最终用户访问的就是这些表

---

关于“正确压缩和分区小数和EBCDIC字符”的部分令人困惑。你是怎么更新SH.PROM的？JDBC？RPG？通过IBMiNavigator运行的SQL语句？为什么注意“适当的压缩和分区小数”很有趣？这是因为SH.PROM是一个平面文件（没有定义实际列），您必须使用SQL内置函数模拟压缩的十进制字段吗？

如果

SH.PROM

加载到

QTEMP

（例如，当用户登录时），则它们仍将保留旧信息而不是更新的信息。如果是这种情况，只需让他们先签字，然后再重新登录，就可以更新他们的本地副本。有什么可以帮助我知道是否正在使用SH.PROM的当前版本吗？这是DSPFD:&如果您的表处于承诺控制之下，更改是否已提交？用户是否能够找到其他促销活动？系统上是否有多个此类文件？（使用

WRKOBJ*ALL/SH.PROM

）如果是这样，请使用WRKJOB选项14查看他们的作业，以查看打开的文件，这些文件将告诉您作业在哪个库中打开了该文件。您可以执行

WRKOBJLCK/SH.PROM*文件

以查看哪些作业/用户在任何给定时间锁定了该文件。这不会告诉你过去谁碰过它，只会告诉你这一秒谁在正确使用它。WarrenT建议查看用户的作业并查看哪些文件处于打开状态，这很有帮助-您可以查看用户使用的是您修改的

SH.PROM

还是其他文件。输出文件如何。记录也可以被缓冲，直到关闭或达到强制比率。如果其他作业已经将文件作为逻辑文件打开，并且延迟了维护，那么索引可能不会更新，直到有人再次打开它。（只要你说“没有其他方法”，你就可以让建议另一种方法的人打开自己；）我在回答中提到了这两种情况。他们似乎不符合被问到的问题——OP多次使用“更新”这个词。我接受了巴克的回答。昨天是一个可怕的星期一。作为一个比我年长的系统的管理员，我犯了一个可怕的新手错误，感到恐慌。我一直试图通过我们的订单/发票应用程序验证促销活动是否正确，顺便说一句，我使用了一个无法查看促销活动的客户编号。我注意到“正确压缩/分区的小数和EBCDIC字符”，以强调这不是数据错误。我知道这是数据库之外的东西。虽然那个外部组件是我，但我考虑了系统的其他部分。我使用了带有SQL的ODBC连接。