LinQ y actualizacion a SQL Server

Veo que los comandos que recibe desde LinQ son a traves del
procedimiento del servidor "sp_executesql", es decir SQL dinamico!.

No sé bien a qué le llamas SQL dinámico, para mí SQL dinámico es cuando la
sentencia se forma a partir de concatenaciones de cadenas, algunas de las
cuales contienen valores (posiblemente introducidos por el usuario).

A diferencia de eso, en el SQL parametrizado todos los valores se
suministran a través de parámetros. TODAS las sentencias q LINQ to SQL
genera son parametrizadas, para evitar inyección de SQL.

...me puso en el WHERE del Update una comparacion para todos los campos
de la tabla,

cuando solo bastaba con preguntar por la clave primaria.

Por defecto, todas las columnas participan en la comprobación de
concurrencia optimista. Pero eso se puede modificar. Copio textualmente:

"La comprobación de si la fila ha sido modificada después que se leyó o no
se lleva a cabo, como es natural, comparando los valores originales de las
columnas de esa fila con los actuales. Una columna se utilizará o no en
esta comprobación en dependencia del valor que se asigne al parámetro
UpdateCheck del atributo Column asociado a la columna en la clase de
entidad. Los posibles valores son UpdateCheck.Always (utilizar la columna
siempre, el valor por defecto), UpdateCheck.Never (no utilizar la columna
en las comprobaciones) y UpdateCheck.WhenChanged (utilizarla solo cuando
el valor de la columna haya sido modificado)."

Quizas la razon sea que para forzar a que sean parametrizadas
necesariamente tengan que armarse con sp_executesql. Ya eso seria una
explicacion pero eso tambien las haria menos eficientes en llamadas
frecuentes porque tengo entendido que con sp_executesql nunca se guardan
las rutas de ejecucion.

Una precisión.
Con el comando EXEC se daba eso que dices. Pero el Sp_ExecuteSQL se creó
precisamente para hacer mas eficientes las llamadas consecutivas usando
SQL dinámico cuando lo único que se haya variado en el comando sean los
valores de los parámetros. Si eso ocurre, ciertamente sí se guardan los
planes de ejecución por tanto no hay que preocuparse por la eficiencia en
este caso ya que para esos fines (solo diferencia en los valores de los
parametros) es prácticamente igual que haber armado la cadena en la
aplicación o tener un SP personalizado.

Ahora bien, si quieres un plan de ejecución siempre precompilado pues
entonces créate un store procedure pero no te sorprenda que al postear una
llamada desde la aplicación también se convierta a otra llamada intermedia
al Sp_ExecuteSQL. Sería normal en ese caso.

>

Quizas la razon sea que para forzar a que sean parametrizadas
necesariamente tengan que armarse con sp_executesql. Ya eso seria una
explicacion pero eso tambien las haria menos eficientes en llamadas
frecuentes porque tengo entendido que con sp_executesql nunca se guardan
las rutas de ejecucion.

Una precisión.
Con el comando EXEC se daba eso que dices. Pero el Sp_ExecuteSQL se creó
precisamente para hacer mas eficientes las llamadas consecutivas usando
SQL dinámico cuando lo único que se haya variado en el comando sean los
valores de los parámetros. Si eso ocurre, ciertamente sí se guardan los
planes de ejecución por tanto no hay que preocuparse por la eficiencia en
este caso ya que para esos fines (solo diferencia en los valores de los
parametros) es prácticamente igual que haber armado la cadena en la
aplicación o tener un SP personalizado.

Ahora bien, si quieres un plan de ejecución siempre precompilado pues
entonces créate un store procedure pero no te sorprenda que al postear una
llamada desde la aplicación también se convierta a otra llamada intermedia
al Sp_ExecuteSQL. Sería normal en ese caso.


Jose TH

Yo he comprobado practicamente la diferencia entre ejecutar una sentencia
con sp_excutesql con parametros:

Ejecutando la misma sentencia con sp_executesql con diferentes valores de
parametros sucesivamente es bastante mas eficiente que enviar sentencias
que hacen lo mismo sin parametros desde el cliente.


"principiante" escribió en el mensaje de noticias
news:

>

Quizas la razon sea que para forzar a que sean parametrizadas
necesariamente tengan que armarse con sp_executesql. Ya eso seria una
explicacion pero eso tambien las haria menos eficientes en llamadas
frecuentes porque tengo entendido que con sp_executesql nunca se guardan
las rutas de ejecucion.

Una precisión.
Con el comando EXEC se daba eso que dices. Pero el Sp_ExecuteSQL se
creó precisamente para hacer mas eficientes las llamadas consecutivas
usando SQL dinámico cuando lo único que se haya variado en el comando
sean los valores de los parámetros. Si eso ocurre, ciertamente sí se
guardan los planes de ejecución por tanto no hay que preocuparse por la
eficiencia en este caso ya que para esos fines (solo diferencia en los
valores de los parametros) es prácticamente igual que haber armado la
cadena en la aplicación o tener un SP personalizado.

Ahora bien, si quieres un plan de ejecución siempre precompilado pues
entonces créate un store procedure pero no te sorprenda que al postear
una llamada desde la aplicación también se convierta a otra llamada
intermedia al Sp_ExecuteSQL. Sería normal en ese caso.


Jose TH