ado.sql.add(' and the_date =''' +  formatdatetime(yyyy-m-d',date) + '''');
与
ado.sql.add(' and the_date =:date1');
ado.Parameters.ParamByName('Date1').Value:=formatdatetime(yyyy-m-d',date)
一种是不带参数，一种带参数，哪种好一点？我在SQL数据库的情况下，发现一个问题，就是在子查询里面带参数条件查询，如果条件是中文内容的话查询是会出错的，但在ACCESS数据库下未发现任何问题，在SQL数据库不是包含子查询的情况下也不会出错。

------
我的编程起步于ktop，我将永远支持ktop

parambyname 與直接 sql 帶入沒有那一個好或不好, 兩者都要透過 sql engine 來解析, 差在 param 是比較機動性, 它無須一直去修改 sql.text, 而 直接的 sql 是少了讓 sql engine 二次解析的動作, 但我的經驗, 運用在實質的系統上並沒有差太多, 至於使用 param 代入中文會引發錯誤, 未必是 param 的問題, 你必須看前因後果及資料格式與錯誤訊息等判斷才能了解

小弟認為ParamByName最大的好處在於,
ParamByName('FieldDate').asDate:= VarDatetime;
這樣子,
可以透過Engine轉換,
對應不同的SQL日期格式,
而不用擔心不同的SQL,
需要轉換不同的日期格式,
其他資料型別也是相同道理!!

豬寶寶個人的經驗
ParamByName最大的好處是程式易讀跟不必擔心形態轉換的問題
但是相較於直接放sql進去理論上會比較慢

再如果是中文有問題的話
可能要請您用注意看看 中文裡面是不是有' 這類符號
這個可能會造成delphi的誤判

直到d 2007. 還是不支援unicode =.=


===================引 用 ntjrr 文 章===================
ado.sql.add(' and the_date =''' formatdatetime(yyyy-m-d',date) '''');
与
ado.sql.add(' and the_date =:date1');
ado.Parameters.ParamByName('Date1').Value:=formatdatetime(yyyy-m-d',date)
一种是不带参数，一种带参数，哪种好一点？我在SQL数据库的情况下，发现一个问题，就是在子查询里面带参数条件查询，如果条件是中文内容的话查询是会出错的，但在ACCESS数据库下未发现任何问题，在SQL数据库不是包含子查询的情况下也不会出错。

感谢各位大大的指点，我将实际出错的代码贴一下：
ADOQuery1.SQL.Add('select 功能号,功能名 from tb_A');
ADOQuery1.SQL.Add('where 功能号 not in (select 功能号 from tb_B where 用户名=:帐号)');
ADOQuery1.Parameters.ParamByName('帐号').Value:=ComboBox1.Text;
当用户名是张三（中文姓名）时查询结果是不对的，用户名是zs(拼音或英文时)时查询是正确的。
如果不用参数，直接 where用户名=''' combobox.text '''' ，时无论是中文还是英文的查询都是正确的。
我只遇到在上面这一特定情况下才有这问题，其它时候用参数查询，未测到任何问题。

------
我的编程起步于ktop，我将永远支持ktop

try this,
ADOQuery1.SQL.Add('where 功能号 not in (select 功能号 from tb_B where 用户名=[:帐号])');
===================引 用 ntjrr 文 章===================
感谢各位大大的指点，我将实际出错的代码贴一下：
ADOQuery1.SQL.Add('select 功能号,功能名 from tb_A');
ADOQuery1.SQL.Add('where 功能号 not in (select 功能号 from tb_B where 用户名=:帐号)');
ADOQuery1.Parameters.ParamByName('帐号').Value:=ComboBox1.Text;
当用户名是张三（中文姓名）时查询结果是不对的，用户名是zs(拼音或英文时)时查询是正确的。
如果不用参数，直接 where用户名=''' combobox.text '''' ，时无论是中文还是英文的查询都是正确的。
我只遇到在上面这一特定情况下才有这问题，其它时候用参数查询，未测到任何问题。

用户名=[:帐号])');无法运行 =:[账号]的话可以运行，但结果不对。

------
我的编程起步于ktop，我将永远支持ktop

You know, that's the reason why I never use chinese words as a database field name! some weird bugs happen from time to time. 
===================引 用 ntjrr 文 章===================
用户名=[:帐号])');无法运行 =:[账号]的话可以运行，但结果不对。

我现在已经着手将所有字段都改成英文的了，但要过几天我才能测试好，到时我来结案，看是不是这个原因

------
我的编程起步于ktop，我将永远支持ktop

其實我在各種場合經常要說明, Delphi是一套Single Byte(外國語)的軟體, 雖然可以支援Double Byte的結構, 但在Field, var, procedure .. 等等實在不建議使用雙語的型態(如中文), 因為你不知道有那些中文的HigByte 會與Delphi內定的部份衝突, 
所以還是以英文做為各種參數之用才是比較ok的,
還有你的引題, 個人覺得不太舒服, 是因為你最後表達你真正想問的東西, 這與parambyname 與直接下的優劣無關, 建議
你下回有問題直接表達出來, 利用這樣的引語由於我們不知前因後果, 回答時很容易導入錯誤的資訊, 謝謝!
===================引 用 ntjrr 文 章===================
我现在已经着手将所有字段都改成英文的了，但要过几天我才能测试好，到时我来结案，看是不是这个原因

个人觉得这次提问还是没有结束，因为我确实要问的是用参数的利弊，并且取了一个用参数查不到正确结果的例子，但得到Stallion版大的指点，他觉得这不是参数的利弊，而是中文字段和英文字段的问题。所以我还得改为英文测试，如果试了对的，说明用不用参数都不会出错，（并且顺便知道了数据库用中文字段的坏处）。在别处论坛中也得到了很多高手的指点，总结了一下，用参数的好处是参数经过了检查，安全性高，不容易受到攻击。用参数的坏处说特别在日期格式时，容易查询错误，说一般不用参数，但经过我的测试，我发现在多种日期格式下，用不用参数都能查到正确的答案。这些我都想在此得到更多的大大的验证和指点。

------
我的编程起步于ktop，我将永远支持ktop

編輯記錄

如有誤解你的意思, 請包涵!

各抒己见，说的不对也请PD大大包涵，因为是在重构数据库，所以可能需要一周以上时间，但我测试后一定会来结案。

------
我的编程起步于ktop，我将永远支持ktop

经过测试，和中文字段无关，我现在已经将所有的数据库字段都改成了英文的了（因为我知道无论是否这原因，改为英文的总要好一点），在英文字段情况下仍出现下列情况：在SQL数据库中带参数查询就会出错（我说的仅仅是在子查询中带参数才会错），在子查询中直接查询就不会出错。但在ACCESS数据库中子查询带参数查询是正确的。

------
我的编程起步于ktop，我将永远支持ktop

我把代码贴全了：
ado.Close;
ado.SQL.Clear;
ado.SQL.Add('select gnh,gnm from tb_a');
ado.SQL.Add('where gnh not in (select gnh from tb_b where yhm=:yhm)');
ado.Parameters.ParamByName('yhm').Value:=ComboBox1.Text;
ado.Open; 在SQL中ComboBox1.Text中名称为张三，那数据就错，名称为zs，数据就对，在ACCESS中无论叫什么数据都对。
如果写成where yhm=''' combobox1.text ''';那么什么情况下都对。
我再细说一下什么叫对，什么叫错，会不会我自己数据看错了，那其实不可能，因为这个其实就是一个增加权限的代码，如果张三没权限，那么上面代码中会显示所有的功能号和功能名出来，但现在的情况是，给了张三所有权限，再次点增加权限时还是会出来所有权限，但如果给ZS相同的操作，就不会出错。

------
我的编程起步于ktop，我将永远支持ktop

編輯記錄

我曾經有一個經驗, 就是 field 與 var 同名是不行的, 試試看把 :yhm 改為其他, 如 :_yhm

改了一下不同名也出错。

------
我的编程起步于ktop，我将永远支持ktop

不好意思, 我沒轍了, 可能與 SQL 的字碼有關吧!