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, OwnerDatanerData, 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，它的資料來源任意，其中cds1為主資料集，在裡面增加一個新的Lookup字段，這個Lookup字段根據cds1中的一個字元型的字段值在cds2中找出對應值來。
運行程序，一般來說是正常的，但是一旦cds1的被Lookup字段中的值出現了一個單引號"'"（您可以修改或添加一條記錄，輸入單引號試試），立即會導致出錯： Unterminated string constant（未結束的字串常數）。
BUG分析與修復：
這個BUG的產生原因比上一個明顯得多，一定是沒有正確處理單引號帶來的副作用所引起的。
同樣的，我們來追蹤VCL的源碼：
執行程序，出錯時打開Call Stack視窗（在View->Debug Windows）選單中，查看函數呼叫情況，前面的一些呼叫是顯而易見的，沒有問題，我們從跟Lookup有關的地方開始查原因，第一個與Lookup有關的函數呼叫是TField.CalcLookupValue，我們在這個函數中設定斷點，重新運行程序，中斷下來後，進行單步調試。
TCustomClientDataSet.Lookup->TCustomClientDataSet.LocateRecord
經過上面的幾次函數調用，很快的，我們就把目標定在了LocateRecord過程中，在這個過程中，它根據Lookup字段的設置情況，生成相應的過濾條件，然後到目標數據集中把對應的值找到，錯就錯在過濾條件的產生上了。例如，我們要按cds1中Cust欄位（假設是001）的值到cds2中按CustID欄位值來找到對應的CustName欄位值。那產生的條件就應該是[CustID] = '001'，但如果Cust的值是aa'bb，按產生的條件就會變成[CustID] = 'aa'bb'，顯然導致了一個未結束的字串常數。
通常我們解決單引號中又出現單引號的情況，只要把引號中的引號寫兩就行了，這裡也是一樣，只要讓生成的條件變成[CustID] = 'aa''bb'就不會出錯了。所以可以這樣修改原始碼：
在LocateRecord過程中找到下面的程式碼：
ftString, ftFixedChar, ftWideString, ftGUID
if (i = Fields.Count - 1) and (loPartialKey in Options) then
ValStr := Format('''%s*''',[VarToStr(Value)]) else
ValStr := Format('''%s''',[VarToStr(Value)]);
改成：
ftString, ftFixedChar, ftWideString, ftGUID:
if (i = Fields.Count - 1) 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一個不大不小的疏漏。