多层应用中的事务处理，是必须的，如果处理不好，就会出现各种数据不同步的现象，无法投入使用。以前用ASTA实现的多层应用，是在客户端利用ASTA机 制，将要提交的数据集、执行的SQL及SP，统统生成到一个脚本中，在ASTA是TAstaParamList,然后一次性提交到服务器，在服务器端在执 行这个脚本时，开启事务，执行脚本，如果成功则Commit,失败则Rollback。

kbmMW提供了更好的事务处理机制，即可以在服务器端做事务处理（TkbmMWTransactionResolve)也可以在客户端处理（TkbmMWClientTransactionResolve）。

在客户端，只要利用kbmMWClientTransactionResolve.Resolve(Query1,Query2,...)即可实现事务控制，此方法返回True,表明事务提交成功。如果提交失败，服务器端自动Rollback,完成事务回滚。

有几个事件可以捕获提交失败信息。

1.kbmMWClientQuery.OnResolveError事件

2.kbmMWClientTransactionResolve.onResolveError事件

此外，当kbmMWClientQuery在kbmMWClientTransactionResolve提时失败时，kbmMWClientTransactionResolve会为kbmMWClientQuery生成具体的错误记录的信息，保存在kbmMWClientQuery属性中，该属性是kbmMWMemTable类型。

利用这几种方式，可以很好的处理事务失败后的错误提示等进一步处理。

问题是当提交失账时，会产生新的问题：

1.假设有T1,T2两个物理表，需要用户同时修改并提交

2.当用户对T1，T2都做了修改后，用kbmMWClientTransactionResolve.Resolve(T1,T2)提交给服务器，当t2提交失败时，比如主键重复，问题就来了。

3.如果用户修改了T2的主键重复错误，再次提交，这时，不会再产生提交错误。

4.重新打开T1，T2，会发现T1的修改丢失，而T2正常修改了。

这种情况，对用户的操作过程来讲，是大问题，明明改了业务数据，保存时产生错误，按错误提示修正了错误数据，再保存，系统保存成功，再次调出这笔业务数据，用户会发现，修改结果没有被正确的保存！

对开发者来说，就是要在事务提交失败后，能恢复失败前的现场，即要把T1,T2的Delta保存起来，不能因为提交失败，而毁掉T1,T2的修改！

试图查找kbmMW提供现成的机制（其实，感觉不应该发生这样的问题），没有找到。于是想一个方法，就是Resolve前将T1,T2保存起来，提交有错误再恢复。

用AllData方法不行：

代码：

在BeforeResolve事件保存

procedure TForm2.kbmMWClientTransactionResolver1BeforeResolve(Sender: TObject;
  const ADatasets: TkbmMWClientCursorArray);
begin
  v1:=kbmMWClientQuery1.AllData;
  v2:=kbmMWClientQuery2.AllData;

end;

//提交不成功，试图恢复（这里只是测试，正常应恢复没有出错的Query,好能再一次提交）

procedure TForm2.Button2Click(Sender: TObject);
begin
  if not kbmMWClientTransactionResolver1.Resolve([kbmMWClientQuery1,kbmMWClientQuery2,kbmMWClientQuery3]) then begin
    kbmMWClientQuery1.AllData:=v1;//这句出错，提示非法的属性值
    kbmMWClientQuery2.AllData:=v2;
  end;
end;

还有一种方法，就是把delta写入流，提交失败再恢复，不知是否可行？先放一下。

问题一定出在TkbmMWClientTransactionResolver.Resolve方法中，硬着头皮跟踪一下，咱这功力看大侠的套路，心惊胆颤，运气还不错，终于查到，问题出ProcessErrorTable方法中：

procedure TkbmMWCustomPooledCursor.ProcessErrorTable

在这个方法中，这里做了CheckPoint，把Delta干掉了！当提交的数据集没有返回ErrorTalbe时，系统认为这个数据集正确提交，所以做了CheckPoint。

// Check if no errortable defined.
     if (FErrorTable.FieldCount=0) or (FErrorTable.RecordCount<=0) then
     begin
          CheckPoint;
          exit;
     end;

原因找到了，一时间还想不出最好的修改方法来解决这个问题。试图找到一个属性来控制这种行为，也没有找到。等xalion来帮助了！

和xalion讨论该问题，也没有找到kbmMW已有的机制，对于上面提到的问题点，也可以确定。

再进一步分析一下ClientTransactionResolve.Resolve方法的执行过程，大体上分三步：

1.对提交的数据集，制作成Variant数组及Stream

2.将1生成的内容一次性提交到服务器端并接收返回的结果

3.利用返回结果对每一个提交的数据集进行ErrorTable处理，问题就出在这一步上。

首先，kbmMW从返回的结果，生成每个数据集的ErrorTable内容，然后根据ErrorTable，调用ProcessErrorTable方 法，ProcessErrorTable方法有两个主要目的：如果无错，则调用CheckPoint,取消这次提前的修改内容,有错，不调用 CheckPoint,触发OnResolveError事件。

对于一个数据集是否要Checkpoint,不应该取决于当前数据集是否有错，而应该由本次提要的结果来决定，就是说：当事务成功，则每一个数据集都应该做Checkpoint，事务不成功，则对于无错的数据集也不能Checkpoint!

按此想法，对ClientTransactionResolve.Resolve做了修改，测试上面遇到的问题，可以正确保存用户的修改。

修改方法是注册掉原ProcessErrorTable的调用，然后增加下面的代码，核心那行，我加黑了！

cnt:=0;
              for i:=low(ADatasets) to high(ADatasets) do
              begin
                   with ADatasets[i] do
                   begin
                        if not IsDataModified then continue;
                        v:=vResult[cnt];
                        inc(cnt);
                        if VarIsNull(v) then continue;
                        if VarArrayHighBound(v,1)>2 then
                           sFlags:=v[3]
                        else
                           sFlags:='';
                        NoCheckpointOnError:=(pos('NOCHECKPOINTONERROR',sFlags)>0);

DisableMasterDetail;
                        try
                           bm:=GetBookmark;
                           try
                              //如果整体事务成功或者当前表有错误
                              if Result or (ErrorTable.RecordCount>0) then
                                 ProcessErrorTable(TransactionOperation<>mwtoResolve,NoCheckpointOnError);
                           finally
                              try
                                 GotoBookmark(bm);
                              except
                              end;
                              FreeBookmark(bm);
                           end;
                        finally
                           EnableMasterDetail;
                        end;
                   end;
              end;