¿Los componentes ADO, especialmente TADOCommand, funcionan de manera más fiable con parámetros sin nombre o con nombre, en algunos casos?

Question

Hay varias preguntas en StackOverflow que parecen tener respuestas que se contradicen entre sí sobre el tema de ADO/OleDB, delphi TADOQuery/TADOCommand y el tema de los parámetros.

Los parámetros se pueden introducir de dos maneras, en las propiedades CommandText o SQL de un componente ADO. Los parámetros con nombre, que trabajan la mayoría de las veces para mí, se introducen con dos puntos:

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

Esto funciona, el 99% de las veces para mí, muy bien. De vez en cuando me parece que ADO o envoltorios de Delphi a su alrededor, no aceptarán ": Baz" y requiere que escribo esto en su lugar:

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

Esto se traduce en un parámetro sin nombre, en lugar de un parámetro con nombre. Cuando un comando ADO Query o ADO contiene solo un parámetro, esto no es un gran problema. Pero eso no es cuando ADO se porta conmigo. Ayer actuó de una manera, y hoy en día, de una manera diferente con un doble mando en un solo objeto TADOCommand, así, con dos comandos en cadena de un CommandText:

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

tuve que cambiarlo a esto:

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

Funcionó todo el día de ayer. Hoy tuve que cambiarlo a la primera versión para que funcione. El síntoma era que los parámetros de ADO desaparecían y no regresaban, y cuando intento ejecutar el comando obtengo un error, índice fuera de rango, cuando intento acceder al Parameters[0]. Nada me da ninguna advertencia de que los parámetros están desapareciendo. Parece que unas pocas conexiones al conjunto de datos ADO, en designtime, activan el componente TADOCommand, en particular, y "simplemente me rompe". Es particularmente enloquecedor cuando intentas escribir una consulta o un comando, y sabes que funciona, pero el componente ADO ha decidido no aceptar "?" o ": x" en este momento. Puede evitar su incapacidad total para funcionar cambiando de una a la otra. Pero me frustra, y probablemente bloquea completamente a otras personas. Sé que algunas personas siempre construyen dinámicamente su SQL en código, y evitan usar Parameters, y quizás por eso.

posibles respuestas a la pregunta que yo estoy anticipando son:

1. ADO no admite varios comandos, o al menos envoltorios de Delphi no lo hacen. O tal vez TADOCommand simplemente no funciona de manera confiable aquí.

2. Los parámetros son un área defectuosa en todos los ADO, o en todos los envoltorios ADO de Delphi?

3. Lo estás haciendo mal.

Estoy usando Delphi XE2, pero he visto un comportamiento igualmente dudoso en 2007, 2009, 2010 y XE. Estoy usando Proveedor OLEDB de Microsoft para SQL Server como mi Proveedor OLEDB.

Answer 1

Sí, hay algunos casos en los que los parámetros con ? fallan. He encontrado que a veces necesito usar los parámetros :named. Los parámetros con nombre tienen una ventaja para trabajar con los valores del parámetro DB, ya que tener la propiedad Nombre establecida hace que la depuración de la consulta ADO o el conjunto de datos o la tabla también sea más fácil.

No entiendo por qué. Si tiene este problema, primero verifique que esté usando el proveedor OLEDB correcto y verifique la versión. También verifique si hay errores de análisis potenciales causados ​​por un SQL incorrecto generado por usted.

Sospecho que un comportamiento interno dentro del proveedor OLEDB en el código que no tengo el código fuente es el culpable de esta peculiaridad. Las envolturas de clase Delphi ADO son traductores de la arquitectura de capa de componentes de base de datos de Delphi a las API de API de consulta/tabla/conjunto de datos de ADO, todas ellas cubiertas por un conjunto de objetos COM que se ocupan de ADO RecordSets.

Answer 2

Desafortunadamente, hace mucho tiempo que no uso Delphi y no tengo los medios para validar esta respuesta desde la perspectiva Delphi.

Esta es la primera vez que he visto parámetros con el prefijo de dos puntos (:).Por lo general, en ADODB, los parámetros nombrados tienen un prefijo at (@) y, sí, los parámetros sin nombre se dan con un signo de interrogación (?).

Una ventaja significativa de los parámetros con nombre es su capacidad para ser reutilizado, es decir

INSERT INTO TABLE T VALUES (@id, @id, 'Hello World'); 

A nivel ADODB. Una vez que haya utilizado los parámetros, ya sea con nombre o sin nombre, puede usar CommandText.Parameters.Refresh como medio rápido para crear los parámetros.

Answer 3

Parámetros nombrados con :? Siempre lo usé con @, incluso en Visual Studio (ADO.NET). Y en los parámetros de T-SQL y la variable llevan el prefijo @.

no recuerdo haber tenido problemas con eso ... ¿Seguro que no elige Native Client (instalado con un cliente de servidor de SQL instalar) en lugar del proveedor OLEDB para SQL Server (que viene con Windows)?