Select con variables en sp

02/09/2005 - 00:55 por Alex | Informe spam

Hola amigos,
estoy tratando de ejecutar este codigo y tengo problemas con las comillas,
no tengo idea de como hacer par que se ejecute la sgte. sentecia: Select *
from compras where idtipodocumento='01', el problema es como reemplazo los
apostrofes.

declare @tabla varchar(10), @tpo char(2)
declare @cad varchar(500)
set @tabla='COMPRAS'
set @tpo='01'
set @cad=('select * from '+@tabla+' where idtipodocumento="'+@tpo+'"')
exec (@cad)

Espero por favor su valiosa colaboración. Gracias.

Atte.
Alex Carmen Z.
Peru

Siga el debate

12 respuestas

Tengo una respuesta

Preguntas similare

Generar Select con criterios de busqueda variables

Leer las respuestas

#6 Alejandro Mesa

02/09/2005 - 16:14 | Informe spam

Maxi,

No veo a que biene esa aclaracion. En ningun momento se ha dicho que sql
server no mantiene en cache la sentencia ejecutada por sp_executesql.

Si envias la sentencia desde la aplicacion cliente (como recomienda Ivan),
implicaria muchas mas cosas en contra y no solo hablo de seguridad. Tener el
codigo de la bd de forma centralizada, como son los sp, ayuda a que cuando se
necesite una modificacion, esta se haga de forma transparente para la
aplicacion cliente. Si armas la sentencia de forma dinamica en la aplicacion
cliente, entonces existe mayor probabilidad de que se pueda inyectar codigo
hacia sql server.

Ademas de seguridad, existen otros puntos donde el uso de sql dinamico no
nos ayuda, como por ejemplo el hecho de que no se hace una referencia directa
a los objetos y por lo tanto sql server no puede llevar un control de
dependencias. El clasico ejemplo es:

create procedure dbo.usp_p1
@table sysname
as
set nocount on

declare @sql nvarchar(4000)

set @sql = N'select c1, c2, c3 from' + quotename(@table)

exec sp_execute @sql

return @@error
go

En estos casos, ni se reusa el plan de ejecucion, ni se actualiza las
dependencias en sql server sobre las tablas o vistas referenciadas por el sp.

Mostrar la cita
No se que es un ORM. Habras querido decir CRM (Customer Relationship
Managment)?

Hago una invitacion extensiva a leer el articulo adjuntado anteriormente
"Las virtudes y maldades del SQL dinámico".

AMB

"Maxi" wrote:

Mostrar la cita

Responder a este mensaje

#7 Maxi

02/09/2005 - 16:17 | Informe spam

Hola, sip, tenes razon!! te entendi que por performance era malo usar
sql-dinamico en un SP, mil disculpas

Salu2
Maxi

"Alejandro Mesa" escribió en el
mensaje news:
Mostrar la cita

Responder a este mensaje

#8 Alejandro Mesa

02/09/2005 - 16:35 | Informe spam

Maxi,

No son necesarias las disculpas, solo hice una aclaracion.

Saludos,

AMB

"Maxi" wrote:

Mostrar la cita

Responder a este mensaje

#9 Maxi

02/09/2005 - 16:40 | Informe spam

Ahh, me olvide, un ORM es un mapeador de objetos hacia una Base de datos, o
sea, transforma el mundo de los objetos en mappers para el mundo relacional

Salu2
Maxi

"Alejandro Mesa" escribió en el
mensaje news:
Mostrar la cita

Maxi,

No son necesarias las disculpas, solo hice una aclaracion.

Saludos,

AMB

"Maxi" wrote:

Mostrar la cita
Hola, sip, tenes razon!! te entendi que por performance era malo usar
sql-dinamico en un SP, mil disculpas

Salu2
Maxi

"Alejandro Mesa" escribió en el
mensaje news:
> Maxi,
>
> No veo a que biene esa aclaracion. En ningun momento se ha dicho que
> sql
> server no mantiene en cache la sentencia ejecutada por sp_executesql.
>
> Si envias la sentencia desde la aplicacion cliente (como recomienda
> Ivan),
> implicaria muchas mas cosas en contra y no solo hablo de seguridad.
> Tener
> el
> codigo de la bd de forma centralizada, como son los sp, ayuda a que
> cuando
> se
> necesite una modificacion, esta se haga de forma transparente para la
> aplicacion cliente. Si armas la sentencia de forma dinamica en la
> aplicacion
> cliente, entonces existe mayor probabilidad de que se pueda inyectar
> codigo
> hacia sql server.
>
> Ademas de seguridad, existen otros puntos donde el uso de sql dinamico
> no
> nos ayuda, como por ejemplo el hecho de que no se hace una referencia
> directa
> a los objetos y por lo tanto sql server no puede llevar un control de
> dependencias. El clasico ejemplo es:
>
> create procedure dbo.usp_p1
> @table sysname
> as
> set nocount on
>
> declare @sql nvarchar(4000)
>
> set @sql = N'select c1, c2, c3 from' + quotename(@table)
>
> exec sp_execute @sql
>
> return @@error
> go
>
> En estos casos, ni se reusa el plan de ejecucion, ni se actualiza las
> dependencias en sql server sobre las tablas o vistas referenciadas por
> el
> sp.
>
>> eficiente como usar Stores, es mas, muchos ORM (incluso el de Ms)
>> utilizan
>> Sql-Dinamico.
>
> No se que es un ORM. Habras querido decir CRM (Customer Relationship
> Managment)?
>
> Hago una invitacion extensiva a leer el articulo adjuntado
> anteriormente
> "Las virtudes y maldades del SQL dinámico".
>
>
> AMB
>
>
>
> "Maxi" wrote:
>
>> Hola amigo!! debo ser una de las personas que mas protesto contra el
>> SQL
>> dinamico :-) pero debo aclarar una cosa.
>>
>> En lo que respecta a performance no es malo usar SQL-Dinamico (en la
>> version
>> 2000), esta version mantiene un Cache y si se utiliza Sp_executeSql es
>> eficiente como usar Stores, es mas, muchos ORM (incluso el de Ms)
>> utilizan
>> Sql-Dinamico.
>>
>> Ahora, quiero aclarar algo, el Sql-Dinamico es muy malo para la
>> seguridad
>> y
>> de ser utilizado solo lo hemos puestos en consultas muy complejas
>> donde
>> el
>> uso de SP's era casi imposible (para la seguridad hemos usado Roles de
>> Aplicacion)
>>
>> Con esto no quiero decir que estoy a favor del SQL-Dinamico ni en
>> contra,
>> lo
>> que no veo logico es usar SQL dinamico para lo que muchos
>> desarrolladores
>> lo
>> intentan usar, por ej Delete from @tabla o cosas similares.
>>
>> Voy a ver si me hago algo de tiempo y puedo escribir un documento
>> donde
>> podamos ver como usar SQL-Dinamico y no morir en el intento :-)
>>
>> Un abrazo
>>
>>
>> Salu2
>> Maxi
>>
>>
>> "Alejandro Mesa" escribió en
>> el
>> mensaje news:
>> > Ivan,
>> >
>> >> Lo que yo haria es enviar la instruccion Select direactamente del
>> >> codigo
>> >> fuente desde donde llamas a SqlServer, como puede ser por ejemplo
>> >> Visual
>> >> Basic.
>> >
>> > Como bien dijo Maxi, trataria de evitar sql dinamico. Adjunto un
>> > link
>> > para
>> > que lean sobre los pros y contras de sql dinamico. Pero tampoco
>> > estoy
>> > de
>> > acuerdo con tu recomendacion, y de seguro Maxi estara de acuerdo
>> > conmigo,
>> > pues no solo que habres una brecha para la injeccion de codigo hacia
>> > sql
>> > server, sino que obligas a sql server a que cada vez que ebvies la
>> > sentencia,
>> > este tenga que hacer un chequeo de sintaxis, compilar la sentnecia y
>> > luego
>> > ejecutarla. como vez no haces uso de los planes de ejecucion en el
>> > cache,
>> > facilidad que puede ayudar mucho en el rendimiento de tu aplicacion.
>> >
>> > Las virtudes y maldades del SQL dinámico
>> > http://www.hayes.ch/sql/sql_dinamico.html
>> >
>> > Cómo aprovechar las ventajas de las características integradas de
>> > ASP.NET
>> > para rechazar los ataques a través de Internet (artículos técnicos
>> > sobre
>> > ASP.NET)
>> > http://www.microsoft.com/spanish/ms...rriers.asp
>> >
>> >
>> > AMB
>> >
>> > "Ivan Pascual" wrote:
>> >
>> >> En tu caso lo que yo haria es evitar el SQL dinamico, que es como
>> >> se
>> >> solucionaria tu duda.
>> >> Como muy bien apunta el sabio Maxi no es una buena practica
>> >> utilizar
>> >> esta
>> >> metedologia.
>> >>
>> >> Lo que yo haria es enviar la instruccion Select direactamente del
>> >> codigo
>> >> fuente desde donde llamas a SqlServer, como puede ser por ejemplo
>> >> Visual
>> >> Basic.
>> >>
>> >> No se si me explico.
>> >>
>> >> Ivan Pascual
>> >>
>> >> "Eleazar" escribió en el mensaje
>> >> news:
>> >> > HOLA trata asi
>> >> > set @cad='select * from '+@tabla+' where idtipodocumento>> >> >> > "'+@tpo+'"'
>> >> >
>> >> > "Alex" escribió en el mensaje
>> >> > news:uI%
>> >> > > Hola amigos,
>> >> > > estoy tratando de ejecutar este codigo y tengo problemas con
>> >> > > las
>> >> comillas,
>> >> > > no tengo idea de como hacer par que se ejecute la sgte.
>> >> > > sentecia:
>> >> > > Select
>> >> *
>> >> > > from compras where idtipodocumento='01', el problema es como
>> >> > > reemplazo
>> >> los
>> >> > > apostrofes.
>> >> > >
>> >> > >
>> >> > > declare @tabla varchar(10), @tpo char(2)
>> >> > > declare @cad varchar(500)
>> >> > > set @tabla='COMPRAS'
>> >> > > set @tpo='01'
>> >> > > set @cad=('select * from '+@tabla+' where
>> >> > > idtipodocumento="'+@tpo+'"')
>> >> > > exec (@cad)
>> >> > >
>> >> > > Espero por favor su valiosa colaboración. Gracias.
>> >> > >
>> >> > > Atte.
>> >> > > Alex Carmen Z.
>> >> > > Peru
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >>
>> >>
>> >>
>>
>>
>>

Responder a este mensaje

#10 Alejandro Mesa

02/09/2005 - 17:11 | Informe spam

Maxi,

Me confundi con las siglas, pues estoy estudiando la metodologia de Terry
Halpin para modelar bases de datos relacionales en la etapa conceptual.

ORM
http://www.orm.net/index.html

AMB

"Maxi" wrote:

Mostrar la cita

Responder a este mensaje

Ads by Google

Hacer una pregunta Siguiente

Tengo una respuesta

1 2 3

Busqueda sugerida