在某些情况下,ADO组件(尤其是TADOCommand)是否可以更加可靠地使用未命名或命名的参数？

Question

StackOverflow上有几个问题似乎有关于ADO/OleDB,delphi TADOQuery/TADOCommand和参数主题的相互矛盾的答案.

可以在ADO组件的CommandText或SQL属性中以两种方式引入参数.大多数时候都为我工作的命名参数是用冒号引入的:

  select a, b, c from bar where bat = :baz

这对99%的时间对我有用,就好了.偶尔我会发现ADO或Delphi的包装器不会接受":baz"并要求我写这个:

  select f, g, h from bar where bat = ?

这会生成一个未命名的参数,而不是命名参数.当ADO查询或ADO命令只包含一个参数时,这不是什么大问题.但是当ADO对我不利时,情况并非如此.昨天它采取了一种方式,今天,在单个TADOCommand对象中使用双命令的另一种方式,就像这样,在一个CommandText字符串中有两个命令:

delete from bar where id = :id1
delete from bat where id = :id2

我不得不改变它:

delete from bar where id = ?
delete from bat where id = ?

它整天都在工作.今天,我不得不将其改回第一版,以使其发挥作用.症状是ADO参数消失了,不会再回来,当我尝试执行命令时,我得到一个错误,索引超出范围,当我尝试访问时Parameters[0].什么都没有给我任何关于参数消失的警告.似乎在ADO数据集的一些连接,在设计时TADOCommand,尤其是对组件进行慢跑,它"只是打破了我".当你尝试编写查询或命令时,它特别令人抓狂,你知道它有效,但是ADO组件决定不接受"？" 或":x"现在.你可以通过从一个切换到另一个来解决它无法运行的问题.但它让我感到沮丧,可能实际上完全阻止了其他人.我知道有些人总是在代码中动态构建SQL,并且避免使用Parameters,也许这就是原因.

我期待的问题的可能答案是:

1. ADO不支持多个命令,或者至少Delphi的包装器不支持.或者也许TADOCommand只是在这里不可靠.

2. 参数是所有ADO中的错误区域,还是所有Delphi的ADO包装器？

3. 你这样做是错的.

我正在使用Delphi XE2,但我在2007,2009,2010和XE中看到过类似的狡猾行为.我正在使用Microsoft OLEDB Provider for SQL Server作为我的OLEDB Provider.

Answer 1

是的，在某些情况下参数会?失败。我发现有时我需要使用:named参数。命名参数在处理数据库参数值时具有优势，因为设置 Name 属性也使得调试 ADO 查询或数据集或表变得更加容易。

我不懂为什么。如果您遇到此问题，请首先检查您使用的是正确的 OLEDB 提供程序，并检查是什么版本。还要检查由您生成的错误 SQL 引起的潜在解析错误。

我怀疑 OLEDB 提供程序内部代码中的内部行为（我没有源代码）是造成此怪癖的原因。Delphi ADO 类包装器是从 Delphi 的数据库组件层体系结构到 ADO 的核心查询/表/数据集 API 的翻译器，所有这些 API 都位于一组处理ADO RecordSets的 COM 对象的底层包装器中。