LinQ y actualizacion a SQL Server

04/10/2007 - 16:18 por Jose Luis | Informe spam
Disculpen las preguntas reiteradas sobre LinQ en este foro pero es que
estado buscando otro newsgroup en español y no lo he encontrado.

Empece a hacer pruebas del linq de Orcas beta2 con SQL Server 2000 leyendo
una tablita y actualizando una columna de tres columnas, siendo la primera
columna su clave primaria. Me la lee y actualiza muy bien pero la inquietud
es que en el SQL Profiler (herramienta para visualizar los comandos que
'recibe' el servidor) veo que los comandos que recibe desde LinQ son a
traves del procedimiento del servidor "sp_executesql", es decir SQL
dinamico!.

En SQL Server siempre se nos dice que evitemos el SQL dinamico por su
ineficiencia e inseguridad. La pregunta es si LinQ siempre ejecutará sql
dinámico hacia el servidor SQL o hay alguna manera de configurarlo para que
no postee sql dinámico sino instrucciones directas?


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?


Jose Luis

Preguntas similare

Leer las respuestas

#11 Jose Luis
04/10/2007 - 22:47 | Informe spam
Mostrar la cita
Yo me referia al SQL dinamico que se arma en el servidor a traves de
sp_executesql o la instruccion Exec, ya que el que llega "armado" desde la
aplicacion no se maneja igual. Se ve en el SQL Profiler.

Mostrar la cita
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.


Mostrar la cita
Ok lo voy a revisar pues eso es lo que quiero, ver como configurarlo.

gracias.

Jose Luis
#12 principiante
04/10/2007 - 23:19 | Informe spam
Mostrar la cita
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
#13 Jose Luis
04/10/2007 - 23:44 | Informe spam
Mostrar la cita
Ok gracias por la explicación, pensaba que el sp_executesql funcionaba igual
que el exec.
Lo estuve chequeando en los BOL y es asi como dices.


Saludos

Jose Luis
#14 Jose Antonio
04/10/2007 - 23:51 | Informe spam
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:
Mostrar la cita
#15 principiante
05/10/2007 - 00:02 | Informe spam
Hola Jose ( Por cierto, este hilo está lleno de tocayos ;-) )

Bueno, eso confirma lo que le estoy explicando a Jose Luis que no hay que
preocuparse por el uso del sp_executesql. Yo sí me preocuparía por el otro
tema del update y cuando Linq manda codigo innecesario o redundante.

Jose TH


"Jose Antonio" escribió en el mensaje
news:
Mostrar la cita
Ads by Google
Search Busqueda sugerida