Select con variables en sp

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
>> > >
>> > >
>> >
>> >
>>
>>
>>

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
>> > >
>> > >
>> >
>> >
>>
>>
>>

Maxi,

No son necesarias las disculpas, solo hice una aclaracion.

Saludos,

AMB

"Maxi" wrote:

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
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >>
>> >>
>> >>
>>
>>
>>

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:

Maxi,

No son necesarias las disculpas, solo hice una aclaracion.

Saludos,

AMB

"Maxi" wrote:

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
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >>
>> >>
>> >>
>>
>>
>>

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:

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:
> Maxi,
>
> No son necesarias las disculpas, solo hice una aclaracion.
>
> Saludos,
>
> AMB
>
> "Maxi" wrote:
>
>> 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
>> >> >> > >
>> >> >> > >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>