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

【问题标题】：AS/400: Why would DB2 table changes not immediately take effect throughout entire system?AS/400：为什么 DB2 表更改不会立即在整个系统中生效？
【发布时间】：2014-02-03 18:30:57
【问题描述】：

我遇到了一个问题，我在后端的 AS/400 - db2 中更新了一个表，但这些更改没有反映在前端。

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

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

【问题讨论】：

如果SH.PROM 被加载到QTEMP 中（例如当用户登录时），那么他们仍将保留旧信息而不是您的更新信息。如果是这种情况，只需让他们注销然后重新启用即可更新其本地副本。
有什么可以帮助我判断是否正在使用 SH.PROM 的当前版本？这是 DSPFD：i.imgur.com/xswA5V8.jpg & i.imgur.com/wBjkC2w.jpg
如果您的表处于提交控制之下，是否已提交更改？
用户能否找到其他促销活动？系统上是否有多个这些文件？（使用WRKOBJ *ALL/SH.PROM）如果是这样，请使用 WRKJOB 选项 14 查看他们的作业以查看打开的文件，这将告诉您作业在哪个库中打开了该文件。
您可以通过WRKOBJLCK <library_name>/SH.PROM *FILE 来查看在任何给定时间哪些作业/用户锁定了文件。这不会告诉你谁在过去接触过它，而只会告诉你谁在就在这一秒使用它。 WarrenT 建议查看用户的工作并查看打开了哪些文件很有帮助 - 您将能够查看用户使用的是您修改的 SH.PROM 还是不同的。

标签： ibm-midrange db2-400

【解决方案1】：

假设您正在使用 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？角色扮演游戏？ SQL 语句通过 IBM i Navigator 运行？为什么注意“正确的压缩和分区小数”很有趣？是因为 SH.PROM 是一个平面文件（没有定义实际的列）并且您必须通过使用 SQL 内置函数来模拟压缩十进制字段吗？

【讨论】：

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