请帮助我，我执行
ALTER TABLE MY_TABLE DATA CAPTURE NONE;
ALTER TABLE MY_TABLE ALTER MY_COLUMN DROP NOT NULL;
但后来我遇到了错误：
SQL状态：57007
供应商代码：-910
消息：[SQL0910] MY_TABLE对象类型* FILE MY_SCHEMA有待更改。
原因。 。 。 。 。 ：MY_TABLE对象有一个 在承诺控制下进行的未决变更阻止了这一点 操作。您可能已经产生以下情况之一：
此应用程序进程已对此对象执行了操作 在承诺控制下。交易未提交。该 应用程序进程现在尝试使用更改相同的对象 承诺控制水平*无。
不同的流程应用程序 在承诺控制下对此对象执行了操作。 交易未提交。
此申请流程有 使用a在承诺控制下对此对象执行操作 承诺的不同定义。交易未提交。
此应用程序进程已在承诺控制下对此对象执行了操作。交易未提交。
在提交或回滚更改之前，您无法更改表。
检索。执行以下操作之一并重试请求：
如果你的申请 进程发出了未提交的操作，运行COMMIT或ROLLBACK 在对此对象进行任何其他操作之前，或者发出 使用除*以外的承诺控制级别的程序声明 NONE。
如果发出未申请的申请流程 对这个对象的操作不是你的应用程序，那么 应用程序进程必须执行COMMIT或ROLLBACK。
如果 应用程序进程使用不同的方式发出了未提交的操作 承诺的定义，对定义发出COMMIT或ROLLBACK 承诺。
在尝试ALTER之前发出COMMIT或ROLLBACK 关于这个主题的TABLE声明。
请帮助我!!
答案 0 :(得分：1)
该条件表明承诺控制下的先前工作尚未完成;等待正常的COMMIT或ROLLBACK，或者先前的处理被中断并且作业已经结束而无法清除提交定义。在作业日志中记录先前的消息，以告知更多的情况，而不是sqlcode = -910和msg SQL0910可以显示的情况;假脱机的作业日志会显示，很可能是先前的带有激活组和逻辑工作单元的msg CPF325E，前面是带有原因码的带有CPG的错误CPF70A6。如果没有假脱机的作业日志，并查看此类已记录的消息，则不太可能学习起源;但是，可以选择使用Work With Commitment Def [inition]（WRKCMTDFN）[以及搜索所有作业的选项]，并且如前所述，查看期刊请求但从未提交的交易。
如果由不再存在的中断进程发起，则IPL将在SCPF作业日志中运行日志/提交/数据库恢复阶段[该IPL时间作业将后续作业日志假脱机化IPL的系统部分完成;即查看活动的SCPF作业日志没有帮助]，并且消息记录到QSYSOPR和/或QHST [除了在发布后的IPL的SCPF作业中假脱机的QPJOBLOG之外，还请参见DSPLOG QHST]。
如果在IPL之后问题仍然存在，那么* ALL的回收存储（RCLSTG）[可选地省略其他任何内容;虽然最好不要省略* DBXREF，但是当重新创建或以其他方式对先前有错误/恢复活动的数据库文件执行工作时，丢失数据库更改可能会在以后显示为错误 - 虽然如果省略SELECT（* ALL）请求，第二个请求可能只是RCLSTG SELECT（* DBXREF）。
注意：过去存在缺陷，即在承诺控制下未执行错误地将文件保留在恢复中，并指示先前的工作是在承诺控制下完成的;效果与不同的消息标识符差别不大，这样在两种情况下都可以保护文件待处理工作免受其他更改活动的影响。允许删除在隔离下运行的工作之外的中断工作，例如使用删除文件（DLTF）或DROP TABLE - 数据库会忽略请求期间记录的错误，但请注意查看指示可能的条件的消息遇到挂起问题，例如该成员未被删除，这意味着无论创建，恢复或添加成员，文件的替换都将失败。只有联系服务提供商才能解决这些困难。