Delphi中两个BUG的分析与修复

【 tulaoshi.com - 编程语言 】

　　Delphi中两个BUG的分析与修复

　　在使用Delphi 7进行三层数据库开发时，遇到了两个小问题，通过反复试验，终于找出了Delphi 7中的两个小BUG并进行了修复（好像Delphi 6中也有相同的BUG），撰写此文与大家一起分享成功的喜悦。我也是初学Delphi，文中一定存在不少说的不对的地方，还请各位朋友多多指正。

　　BUG1.传参时中文被截断的问题：

　　BUG再现的方法：

　　后台用SQL Server 2000，里面有一个XsHeTong表用于试验，您可以根据您的实际情况进行调整。

　　先创建一个数据服务器：新建项目，创建一个远程数据模块，上面放置ADOConnection、ADODataSet、DataSetProvider各一，并做好相应设置，其中ADODataSet的ComamndText留空，并把它的Option中的poAllowCommandText设置为True。编译运行。

　　再创建客户端程序：新建项目，在窗体上放置DCOMConnection，连上前面上创建的数据服务器，再放置一个ClientDataSet，把它的连接设成这里的DCOMConnection，并设置它的ProviderName为上面的服务器上的DataSetProvider的名字。最后放置DataSource和DBGrid各一并作相应设置用于查看结果，再放置一Button用于测试。

　　在Button的OnClick中写下类似于下面的代码（这里我用了XsHeTong的表和它的两个字段HTH（char 15）、GCMC（varchar 100），您可以根据你的实际测试情况进行调整）：

　　with ClientDataSet1 do
　　begin
　　　Close;
　　　CommandText := 'Insert Into XsHeTong(HTH, GCMC) values(:HTH,:GCMC)';
　　　Params[0].AsString := '12345';
　　　Params[1].AsString := '会截断的中文字';
　　　Execute;
　　　Close;
　　　CommandText := 'Select * from XsHeTong';
　　　Open;
　　end;

　　运行程序，点击按钮，看到记录被插入了，可惜结果并不正确，“会截断的中文字”变成了“会截断”，但没有中文的“12345”倒是正确的插入了。

　　BUG分析与修复：

　　为了对照起见，我试着直接用一个ADOConnection和ADOCommand、ADOTable进行C/S构架测试，结果是正确的，中文字不会被切断。这说明了此BUG只在三层构架上出现。

　　 用SQL Server事件探查器探查提交到SQL Server上运行的语句，发现两层构架与三层构架的情况有以下不同：

　　两层构架：
　　exec sp_executesql N'Insert into XsHeTong(HTH, GCMC) values(@P1,@P2)', N'@P1 varchar(15),@P2 varchar(100)', '12345', '会截断的中文字'

　　三层构架：
　　exec sp_executesql N'Insert into XsHeTong(HTH, GCMC) values(@P1,@P2)', N'@P1 varchar(5),@P2 varchar(7)', '12345', '会截断

　　显然，两层构架时，参数的长度是按实际库结构传的，三层构架时，参数长度是按实际参数的字符串长度传的，而实际字符串长度又似乎是算错了，没有把一个中文当两个字符长度处理。

　　没有办法只好进行跟踪调试，为了调试Delphi的VCL库，需要在工程选项的“Compiler Options”中选上“Use Debug DCUs”。

　　先跟踪客户端程序，ClientDataSet1.Execute后，先后经历了TCustomClientDataSet.Exectue、TCustomeClientDataSet.PackageParams、TCustomClientDataSet.DoExecute等一系列函数，一直到AppServer.AS_Execute(ProviderName, CommandText, Params, OwnerData); 把请求提交到服务器均没有什么异常情况，看来问题出在服务器端。

　　对服务器进行跟踪，反复试验后，我把重点落在了TCustomADODataSet.PSSetCommandText函数身上，经过反复细致的跟踪，目标越来越精确：TCustomADODataSet.PSSetParams、TParameter.Assign、TParameter.SetValue、VarDataSize。终于找到了BUG的源头：VarDataSize函数，下面是它的代码：

　　function VarDataSize(const Value: OleVariant): Integer;
　　begin
　　　if VarIsNull(Value) then
　　Result := -1
　　　else if VarIsArray(Value) then
　　Result := VarArrayHighBound(Value, 1) + 1
　　　else if TVarData(Value).VType = varOleStr then
　　begin
　　　Result := Length(PWideString(@TVarData(Value).VOleStr)^); //出问题的行
　　　if Result = 0 then
　　Result := -1;
　　end
　　　else
　　Result := SizeOf(OleVariant);
　　end;

　　就是在这个函数中计算实参的长度的，它把Value中的值取出地址，并把它作为一个WideString的指针去求字符串长度，结果就导致了“会截断的中文字”这个字符串的长度变成了7，而不是14。

　　问题找到了，解决起来也就不困难了，只要简单的把
　　Result := Length(PWideString(@TVarData(Value).VOleStr)^); //出问题的行
　　改成
　　Result := Length(PAnsiString(@TVarData(Value).VOleStr)^); //没问题了
　　就可以了。

　　但是这样就会导致求英文字符串的长度时长度被加倍了，所以也可以把这一行改成：
　　Result := Length(Value);

　　这样，不管是中文还是英文还是中英混合的字符串就都可求得正确的长度了。这就我至今仍百思不解的问题，为什么Borland要绕个圈子通过指针去求参数值的长度呢？哪位朋友知道的话还请给我解释一下，非常感谢！

　　有些朋友可能会有疑问，为什么在不通过三层构架来做的时候不产生这个字符串被截断的问题呢？答案并不复杂，在直接通过ADOCommand来向SQL Server发送命令时，它是按表结构来决定参数长度的。它会先向SQL Server发一条

　　SET FMTONLY ON select HTH,GCMC from XsHeTong SET FMTONLY OFF

　　来获取表结构。而在三层构架下，TCustomADODataSet内部虽然也是用TADOCommand对象来发命令，但它却在取得表结构的后，并不用这个值来作为传参长度，而是重新去按实际参数来计算长度，结果就导致了错误。

　　BUG2.ClientDataSet的Lookup字段的问题：

　　BUG再现的方法：

　　新建工程，在上面放置两个ClientDataSet，分别为cds1和cds2，它的数据