我们团队中的某些成员编写/维护RPG程序 - 他们共享一个DB2数据库，由日记和未记录的表组成。
如果我们对级别检查进行编译，那么即使我们只是在表中添加新列，那么使用该表的任何RPG程序都会丢弃运行时错误。
如果我们没有级检查，则如果RPG程序使用未命名的表，并且我们从其中一张表中删除了相关的列，则RPG程序可能会插入非 - 新表格，然后未能插入第二个（修改的）表中，从而离开孤立数据（因为我们无法使用交易，因为该表未记录在表中）。
我们想要的是不必在添加列（或增加列的大小等）时重新编译任何内容 - 但不带有数据完整性的风险。
有什么办法可以实现这一目标？
我们想要的是不必在添加列（或增加列的大小等）时重新编译任何内容 - 但不带有数据完整性的风险。
添加列很容易，更改大小是另一个故事...
您需要的是将RPG程序与物理数据布局分开的图层。
只是做两件事
- 用显式格式定义所有LF
- 可以通过LF访问所有RPG程序，而不是通过PF访问。
所以你可能有
A* My Physical file
A UNIQUE
A R MYPFR
A MYKEY 3A COLHDG('Key Field')
A FLD1 10A COLHDG('field 1')
A FLD2 15A COLHDG('field 2')
A FLD3 20A COLHDG('field 3')
A K MYKEY
在您的逻辑中，明确列出所包括的字段...
A UNIQUE
A R MYLFR PFILE(MYPF)
A MYKEY
A FLD1
A FLD2
A FLD3
A K FLD1
您的 do not 想要具有自动使用PF格式的LF。
A UNIQUE
A R MYLFR PFILE(MYPF)
A K FLD1
现在，当您向PF添加列时，只需将所有现有的LF保持不变即可。因此，他们的格式不会更改，即使在级别检查上打开了。
您可以定义新的LF，其中包括需要访问新列的任何RPG程序使用的新列。
是的，您最终会增加更多逻辑。但是，只要"新"逻辑使用与现有的密钥相同，除了几个字节的磁盘空间外，它不会占用任何资源。由于"新"逻辑将使用现有的访问路径。并且存储/维护访问路径是在i。
上获得资源的原因。转到此设置也不是那么困难。
- 建立一个新名称的新PF
- 使用现有PF名称创建新的LF
- 更新现有的LF以指向新的PF并明确列出列。
实际上您可以使用SQL而不是DDS，因此您可以使用DB的一些较新的SQL功能。
IBM RedBook现代化IBM I应用程序从数据库到用户界面以及详细信息之间的所有内容。
但是，使应用程序通过LF层工作的想法已经很长一段时间了。
更改大小
处理增加字段尺寸的最佳方法是添加具有较大尺寸的新版本的新版本，并使用DB触发器保持原始的小版本和较大版本的同步。当然，当将一个值放入较小的列中时，您需要决定该怎么做。