在使用Delphi
进行三层数据库开发时
遇到了两个小问题
通过反复试验
终于找出了Delphi
中的两个小BUG并进行了修复（好像Delphi
中也有相同的BUG）
撰写此文与大家一起分享成功的喜悦
我也是初学Delphi
文中一定存在不少说的不对的地方
还请各位朋友多多指正
BUG传参时中文被截断的问题
BUG再现的方法
后台用SQL Server 里面有一个XsHeTong表用于试验您可以根据您的实际情况进行调整
先创建一个数据服务器新建项目创建一个远程数据模块上面放置ADOConnectionADODataSetDataSetProvider各一并做好相应设置其中ADODataSet的ComamndText留空并把它的Option中的poAllowCommandText设置为True编译运行
再创建客户端程序新建项目在窗体上放置DCOMConnection连上前面上创建的数据服务器再放置一个ClientDataSet把它的连接设成这里的DCOMConnection并设置它的ProviderName为上面的服务器上的DataSetProvider的名字最后放置DataSource和DBGrid各一并作相应设置用于查看结果再放置一Button用于测试
在Button的OnClick中写下类似于下面的代码（这里我用了XsHeTong的表和它的两个字段HTH（char ）GCMC（varchar ）您可以根据你的实际测试情况进行调整）
with ClientDataSet do
begin
Close;
CommandText := Insert Into XsHeTong(HTH GCMC) values(:HTH:GCMC);
Params[]AsString := ;
Params[]AsString := 会截断的中文字;
Execute;
Close;
CommandText := Select * from XsHeTong;
Open;
end;
运行程序点击按钮看到记录被插入了可惜结果并不正确会截断的中文字变成了会截断但没有中文的倒是正确的插入了
BUG分析与修复
为了对照起见我试着直接用一个ADOConnection和ADOCommandADOTable进行C/S构架测试结果是正确的中文字不会被切断这说明了此BUG只在三层构架上出现
用SQL Server事件探查器探查提交到SQL Server上运行的语句发现两层构架与三层构架的情况有以下不同
两层构架
exec sp_executesql NInsert into XsHeTong(HTH GCMC) values(@P@P) N@P varchar()@P varchar() 会截断的中文字
三层构架
exec sp_executesql NInsert into XsHeTong(HTH GCMC) values(@P@P) N@P varchar()@P varchar() 会截断
显然两层构架时参数的长度是按实际库结构传的三层构架时参数长度是按实际参数的字符串长度传的而实际字符串长度又似乎是算错了没有把一个中文当两个字符长度处理
没有办法只好进行跟蹤调试为了调试Delphi的VCL库需要在工程选项的Compiler Options中选上Use Debug DCUs
先跟蹤客户端程序ClientDataSetExecute后先后经历了TCustomClientDataSetExectueTCustomeClientDataSetPackageParamsTCustomClientDataSetDoExecute等一系列函数一直到AppServerAS_Execute(ProviderName CommandText Params OwnerData); 把请求提交到服务器均没有什么异常情况看来问题出在服务器端
对服务器进行跟蹤反复试验后我把重点落在了TCustomADODataSetPSSetCommandText函数身上经过反复细致的跟蹤目标越来越精确TCustomADODataSetPSSetParamsTParameterAssignTParameterSetValueVarDataSize终于找到了BUG的源头VarDataSize函数下面是它的代码
function VarDataSize(const Value: OleVariant): Integer;
begin
if VarIsNull(Value) then
Result :=
else if VarIsArray(Value) then
Result := VarArrayHighBound(Value ) +
else if TVarData(Value)VType = varOleStr then
begin
Result := Length(PWideString(@TVarData(Value)VOleStr)^); //出问题的行
if Result = then
Result := ;
end
else
Result := SizeOf(OleVariant);
end;
就是在这个函数中计算实参的长度的它把Value中的值取出地址并把它作为一个WideString的指针去求字符串长度结果就导致了会截断的中文字这个字符串的长度变成了而不是
问题找到了解决起来也就不困难了只要简单的把
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 HTHGCMC from XsHeTong SET FMTONLY OFF
来获取表结构而在三层构架下TCustomADODataSet内部虽然也是用TADOCommand对象来发命令但它却在取得表结构的后并不用这个值来作为传参长度而是重新去按实际参数来计算长度结果就导致了错误
BUGClientDataSet的Lookup字段的问题
BUG再现的方法
新建工程在上面放置两个ClientDataSet分别为cds和cds它的数据来源任意其中cds为主数据集在里面增加一个新的Lookup字段这个Lookup字段根据cds中的一个字符型的字段值到cds中找出对应值来
运行程序一般来说是正常的但是一旦cds的被Lookup字段中的值出现了一个单引号（您可以修改或新增一条记录输入单引号试试）立即会导致出错 Unterminated string constant（未结束的字符串常量）
BUG分析与修复
这个BUG的产生原因要比上一个明显得多一定是没有正确处理单引号带来的副作用引起的
同样的我们来跟蹤VCL的源码
运行程序出错时打开Call Stack窗口（在View>Debug Windows）菜单中查看函数调用情况前面的一些调用是显而易见的没有问题我们从跟Lookup有关的地方开始查原因第一个与Lookup有关的函数调用是TFieldCalcLookupValue我们在这个函数中设置断点重新运行程序中断下来后进行单步调试
TCustomClientDataSetLookup>TCustomClientDataSetLocateRecord
经过上面的几次函数调用很快的我们就把目标定在了LocateRecord过程中在这个过程中它根据Lookup字段的设置情况生成相应的过滤条件然后到目标数据集中把对应的值找到错就错在过滤条件的生成上了比如我们要按cds中Cust字段（假设是）的值到cds中按CustID字段值找到对应的CustName字段值那生成的条件就应该是[CustID] = 但如果Cust的值是aabb按生成的条件就会变成[CustID] = aabb显然导致了一个未结束的字符串常量
通常我们解决单引号中又出现单引号的情况只需把引号中的引号写两就行了这里也是一样只要让生成的条件变成[CustID] = aabb就不会出错了所以可以这样修改源代码
在LocateRecord过程中找到下面的代码
ftString ftFixedChar ftWideString ftGUID
if (i = FieldsCount ) and (loPartialKey in Options) then
ValStr := Format(%s*[VarToStr(Value)]) else
ValStr := Format(%s[VarToStr(Value)]);
改成
ftString ftFixedChar ftWideString ftGUID:
if (i = FieldsCount ) and (loPartialKey in Options) then
ValStr := Format(%s*[ StringReplace(VarToStr(Value)[rfReplaceAll])])
else
ValStr := Format(%s[ StringReplace(VarToStr(Value)[rfReplaceAll])]);
也就是在生成过滤条件字符串时把条件的过滤值中的单引号全部一个变两
为了确保这样修改的正确性我查看了TCustomADODataSet中的对应的LocateRecord过程（在用TADODataSet中的Lookup字段时不会因单引号出错只在用TCustomClientDataSet时有这样的情况）它的处理方法与TCustomClientDataSet稍有不同它是通过GetFilterStr函数来构造过滤条件的但在GetFilterStr中它正确处理了单引号的问题所以这样来看没有在TCustomClientDataSet的LocateRecord中正确处理单引号的问题确实是Borland一个不大不小的疏漏
