LinQ y actualizacion a SQL Server

Mostrar la cita

Mostrar la cita

De hecho probe de la forma tradicional con un Command plano sin
parametros:
"update estado set nombre='otro' where estado='2' " y ciertamente en el
profiler lo veo que se envio directamente sin usar el sp_executesql,

¿Y como lo envía directamente?

Lo envia igual como si fuese un comando digitado directamente en el Query
Analizer por ejemplo, o sea que no lo transforma en el servidor de SQL en
una llamada previa al sp_executesql sino que lo toma como un comando
directo. Lo puedes apreciar en el Profiler de SQL.


Mostrar la cita

Yo pensaba que o mandabas SQL dinámico o ejecutabas un procedimiento
almacenado.

Si pero el "SQL dinámico" se divide en dos tipos que no son lo mismo
(generado en el servidor y generado en la aplicación). Del que yo estoy
hablando es del ejecutado en el servidor a traves del store procedure:
sp_executesql o la instruccion EXEC del servidor.

El otro tipo de SQL dinamico es el string que uno arma dinámicamente en la
aplicación y luego lo envia como comando terminado al servidor. Esto es
otra cosa, como se ha visto ya que no siempre produce una llamada intermedia
a sp_executesql (aunque en Linq parece que siempre) sino que queda como un
comando directo que el servidor lo interpreta como fijo.


Mostrar la cita

Saludos

Jose Luis

Hola José Luis:

Mostrar la cita

La otra cosa extraña que vi fue a pesar de la tablita tener su clave
primaria (campo 'estado'), un update (SubmitChanges) de una fila para
actualizar el campo 'nombre' 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.

Me podrian explicar al respecto?

Yo aún no he probado LinQ, pero esa extraña forma de hacer los updates ya se
usa en ado.net desde el principio. Cuando se crea un dataadapter y el IDE
configura automáticamente los comandos de inserción, actualización y
eliminación junto con el selectcommand, crea esas larguísimas y
complejísimas consultas, las cuales como tu bien dices, podrían resoverse
con sólo hacer un update sobre la clave principal. Una posible explicación:
Que quieran dar la posibilidad de poder hacer un update sobre un registro en
el que se pueda cambiar la clave principal.

Este sistema puede provocar conflictos si por ejemplo tienes un trigger que
cambia un dato de la tabla en base a otra relacionada. En mi caso, me
sucedió con una tabla de un histórico que actualizaba unos campos de la
tabla principal mediante un trigger. Lo resolví, como es obvio, cambiando
ese updatecommand y dejando solo en el where la clave principal. Por lo que
veo, siguen utilizando el mismo sistema...

Saludos

Pero sigue siendo sql dinamico.

"Jose Luis" <x> escribió en el mensaje de noticias
news:
Mostrar la cita

Mostrar la cita

Mostrar la cita

De hecho probe de la forma tradicional con un Command plano sin
parametros:
"update estado set nombre='otro' where estado='2' " y ciertamente en el
profiler lo veo que se envio directamente sin usar el sp_executesql,

¿Y como lo envía directamente?

Lo envia igual como si fuese un comando digitado directamente en el Query
Analizer por ejemplo, o sea que no lo transforma en el servidor de SQL en
una llamada previa al sp_executesql sino que lo toma como un comando
directo. Lo puedes apreciar en el Profiler de SQL.


Mostrar la cita

Yo pensaba que o mandabas SQL dinámico o ejecutabas un procedimiento
almacenado.

Si pero el "SQL dinámico" se divide en dos tipos que no son lo mismo
(generado en el servidor y generado en la aplicación). Del que yo estoy
hablando es del ejecutado en el servidor a traves del store procedure:
sp_executesql o la instruccion EXEC del servidor.

El otro tipo de SQL dinamico es el string que uno arma dinámicamente en la
aplicación y luego lo envia como comando terminado al servidor. Esto es
otra cosa, como se ha visto ya que no siempre produce una llamada
intermedia a sp_executesql (aunque en Linq parece que siempre) sino que
queda como un comando directo que el servidor lo interpreta como fijo.


Mostrar la cita

Saludos

Jose Luis

Mostrar la cita

Pero sigue siendo sql dinamico.

Para el servidor no.


Jose Luis

Mostrar la cita

Mostrar la cita

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.

Mostrar la cita

Mostrar la cita

...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)."

Salu2 - Octavio