delphi - sirve - libro de ado net pdf

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

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 la propiedad CommandText o SQL de un componente ADO. Los parámetros con nombre, que funcionan la mayor parte del tiempo para mí, se introducen con dos puntos:

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

Esto funciona, el 99% del tiempo para mí, está bien. De vez en cuando me parece que las envolturas de ADO o Delphi a su alrededor no aceptan ": baz" y requieren que escribo esto en su lugar:

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

Esto da como resultado 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, de una manera diferente con un comando dual en un solo objeto TADOCommand, como este, con dos comandos en una cadena 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 a 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, TADOCommand 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 código SQL en SQL Server y evitan el uso de Parameters , y quizás esta sea la razón .

Las posibles respuestas a mi pregunta que estoy anticipando son:

ADO no es compatible con varios comandos, o al menos los envoltorios de Delphi no lo hacen. O quizás TADOCommand simplemente no funciona de manera confiable aquí.
Los parámetros son un área con errores en todos los ADO, o todos los envoltorios ADO de Delphi?
Lo estás haciendo mal.

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

Desafortunadamente, no he usado Delphi por un tiempo, entonces, y no tengo los medios para validar esta respuesta desde la perspectiva Delphi.

Esta es la primera vez que veo parámetros con el prefijo de dos puntos (:). Usualmente, en ADODB, los parámetros nombrados son prefijados con un at ( @ ) y, sí, los parámetros sin nombre se dan con un signo de interrogación ( ? ).

Una ventaja significativa de los parámetros nombrados es su capacidad de ser reutilizados, es decir,

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

En el 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.

Parámetros con nombre:? Siempre lo usé con @ , incluso en Visual Studio (ADO.NET). Y en los parámetros de T-SQL y la variable están prefijados con @ .

No recuerdo haber tenido problemas con eso ... ¿Está seguro de que no elige Native Client (instalado con una instalación de cliente SQL server) en lugar de OLEDB Provider para SQL Server (que viene con Windows)?

Sí, hay algunos casos en los que los parámetros tienen ? fallar. He encontrado que a veces necesito usar :named 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 porque. 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 tratan con ADO RecordSets .