Procedimientos Almacenados - Parametros

Hola, te comento:

Hacer un Sp's generico para todos los campos de una entidad no lleva mas de
5' y no son muchas lineas.

Te comento un truco (no deberia pero bue.. ;), un ERP conocido ha
solucionado este problema de la siguiente forma:

Tiene 2 Sp's para consultas genericas (uno con OR y el otro con AND), que
hace basicamente?

En el del or estan todos los campos seguidos por OR y en el de AND igual. En
la aplicacion tienen una pantalla de busqueda generica, donde el usuario
final selecciona entre usar el metodo AND o el metodo OR.

Bien, te comento, este ERP tiene mas de 5.000 clientes en todo el mundo, y
empresas muy criticas, y este metodo lo tienen implementado desde hace 5
años, como funciona? de mil maravillas, los usuarios generalmente con esta
funcionalidad cumplen el 99% de los casos. Las cosas muy pero muy
especificas las resolvera alguien del depto de sistemas, o a lo sumo podras
hacer un modulo de generacion de querys donde lo que haga es armar un Sp's.

Hacer estas cosas no demora nada en el desarrollo, el tema es que hay que
tener la tecnica y la habilidad, porque si te vas a poner a escribir campo a
campo estas frita!! hay herramientas gratuitas que hacen la tarea por vos, o
tambien algunos trucos de T-sql que con un par de lineas podrias generar
todo el codigo que necesitas.

Voy a ver si escribo un articulo sobre este tema asi se dan cuenta de lo que
digo :-)




Salu2
Maxi


"Danilsa" escribió en el mensaje
news:

Disculpen la intromision pero mira, yo he usado Delphi por mucho tiempo
con
distintas bases de datos (firebird, oracle, sql server incluido) y uno
siempre acostumbra a poner alguna opcion especial para buscar por muchos
tipos de columnas que no estan pre concebidos en el diseño del sistema.
Eso
para los programadores de aplicaciones es algo muy normal. Si fuera a
tener
que hacer un store proc para cada posible combinacion de columnas y
wheres,
order by, etc. pues sin exagerar saldrian cerca de 1000 !!! y si por el
contrario decido hacer un solo procedimiento pues la cantidad de lineas y
condicionales que este tendria seria virtualmente imposible de
programarlo.
Mientras mas campos tengan las tablas en cuestion es peor aun.

El riesgo de la inyeccion de codigo para mi es menor contra el trabajo que
supone hacer eso y uno solo le da permiso a las tablas especificas al
usuario. Y tambien pienso que esa inyeccion no puede ocurrir en la
aplicacion que tiene su propio espacio de memoria si no solo cuando tienes
la generacion dinamica en el propio sP, aunque me sorprendo de que digas
que
si ocurre en la aplicacion. Donde puedo obtener mas informacion sobre
inyeccion de codigo en la aplicacion cliente ? Me podrias dar un link
sobre
ese tema ?

Finalmente, tengo sistemas de años y siempre he usado este método para
esas
consultas especiales y la verdad nunca he visto por una parte problemas de
seguridad ni de rendimiento pues como dice como dice el compañero se
supone
que no son transacciones de uso intensivo.




"Patrick Mac Kay" <pmackay_at_hotmail.com> wrote in message
news:%

Ricardo,

el sql injection se produce por el armado de sql dinamicamente, ya
sea
en el sp o en tu programa. Y respondiento a tu pregunta, si, hago todo

con

SPs, que no son dinámicos. Todo armado y precompilado. Todos los

excecution

plans revisados y depurados al máximo. Todas las consultas optimizadas y

los

indices creados en las tablas, ya sean clustered o no. Además, con sps
minimizas el manejo de permisos en la base de datos, o tu le das todos
los
permisos a todas las tablas para el usuario con que te logeas? o lo dejas
como dueño de la base de datos?

Es exactamente esa complejidad que estas programando en la consulta la
que
hará que el sqlserver pueda obtener los mejores caminos de ejecución. Si

el

sql cambia a cada rato, los caminos no serán los optimos.

Si cambias los datos, cambias el sp, eso es obvio, pero no tocas la
funcionalidad de tu programa. Son ajustes menores. Es la base de
cualquier
desarrolo en capas.

No es ser sp maniaco. Es obtener el mejor resultado de tu servidor de

datos.

Patrick.

"Ricardo" escribió en el mensaje
news:
>
> "Patrick Mac Kay" <pmackay_at_hotmail.com> escribió en el mensaje
> news:
> > Ricardo,
> >
> > por que si armas un select en tu aplicación tienes los siguintes
> > problemas.
> >
> > 1.- Sql Injection (alta probabilidad)
>
> No hablo de sql dinamico en el sp sino generar la instruccion select en

la

> aplicacion ANTES de postearlo al servidor. El riesgo no es mayor que
cuando
> envies un simple select * from directamente sin tenerlo en SP. O tu lo
> haces absolutamente todo con SP ? incluso un simple 'select * from

tabla'

de
> una tabla pequeña ? dependiendo del lenguaje que uses puede ser que
> lo
> estes haciendo sin darte cuenta siquiera. Ese es un tema discutible.
>
> > 2.- No es compilado por el sql, y por lo tanto no puede definir la

mejor

> > ruta de ejecución, algo que para los reportes es vital.
>
> Todo depende de la frecuencia de uso. No todo tiene porque estar
> pre-compilado, sencillamente porque no todo esta previsto en una
aplicacion.
> El habla practicamente de una consulta AD-HOC que si entendi bien, las
> combinaciones que genere para meterla en un SP lo harian sumamente
complejo
> de programar.
>
> >
> > 3.- Complicas el desarrollo por que si cambias algo en tu base de

datos

> > debes tocar el codigo.
> >
>
> Puede ser pero si cambio algo en la base de datos tambien tendre que
"tocar"
> el codigo del SP fijo que recomiendas. Casi es lo mismo. Mas aun la
> aplicacion puede programarse de modo generico sin necesidad de código
"duro"
> como lo es el SP fijo que recomiendas.
>
> >
> > La forma correcta es hacer un SP y seguir lo que te mencionó Maxi de

los

> > isnull.
> >
>
> Los SP's son importantisimos estoy de acuerdo. Yo los uso para la

mayoría

de
> las cosas. Pero "no todo en la vida son SP's". Maxi tiene mucho
fundamento
> en lo que dice pero hay que decir que es "SP maníaco". Hay algunos

casos

> (pocos insisto) donde no hay que ser tan rígido. Todo depende de la
> frecuencia del query y del caso particular que se trate (el cual no lo

sé

> realmente). Ademas no estamos hablando aqui de modificaciones sino de
> consultas.
>
>
> > saludos.
> >
> > Patrick.
> >
> > "Ricardo Passians" escribió en el
> > mensaje
> > news:
> > > Y porque en vez de un procedimiento, mejor armas el select desde tu
> > > aplicación ?
> > > Hay casos (pocos si) donde no es practico tenerlo en un sp. Ahora
bien,
> > si
> > > insistes en ponerlo en un SP deberas manejar en el todas las
> combinaciones
> > > posibles y te convendrias hacer un script tambien desde tu sistema

que

> te
> > > genere el codigo del SP a un archivo, lo cortas y lo pegas en un
create
> > proc
> > > en el query analizer o enterprise manager.
> > >
> > > "Romero Diego" wrote in message
> > > news:%
> > > > Hola
> > > > Todos
> > > >
> > > > Tengo un problema :
> > > > La tabla que describo a continuación tiene muchos campos y tengo

que

> > hacer
> > > > un reporte donde en una lista esten los nombres de los campos y
> > > > el
> > usuario
> > > > seleccione los que desee filtrar, esto se hace desde VB
> > > >
> > > > El problema es como hago un procedimiento almacenado para paserle
los
> > > > parametros segun los campos que seleccione o necesariamente debo
crear
> > > > parametro por campo ?
> > > >
> > > > SELECT IdVehiculo, Numero, IdClase, IdMarca, IdLinea, IdColor,
> > > IdTipoVeh,
> > > > IdTipoMot, AnnoModelo, FecRepotencia, Ejes, NumLlantas, PesoVeh,
> > > Pasajeros,
> > > > PasajPie, CapTanque, NumeroMotor,

SerieChasis,

> > > > Cilindrada, IdTipoCom, IdTipoLla, IdTipoLub, IdMarLla, IdMarLub,
> > > IdEmpresa,
> > > > IdPropietario,
> > > > IdConductor, IdTipoPro,
> > > Adquisicion,IdGrupo,VehPropio,
> > > > IdProveedor, FecCompra, TarjetaProp, CostoCompra, ValorAvaludo,
> > > > ValorAsegurado,ValorCupo, IdAdmon,
> > > > NumContrato,ContratoActivo,FecIngreso,
> > > > FecRetiro,FecVigencia,FecSalida, VidaUtil, FecImpuestos,
DocCompleta,
> > > > Accidentes,ObligaTProd, PolizaSoat,FecSoat,VigSoat,EmpresaSoat
> > > >
> > ,GarantiaAcc,PolizaResCivil,FecResCivil,VigResCivil,
> > > > CertMovilizacion, FecCertMovil, VigCertMovil, TarjetaOperacion,
> > > FecTarjOper,
> > > > VigTarjOper, CertGases, FecCertGases, VigCertGases,
> > > > Kilometraje, KmsCompra,
> > > > Observacion,CentInicial,CentFinal,CupoCredito,SaldoActual,
> ArchivoFoto,
> > > > IdEstado, FechaAdd, FechaUpdate, IdUsuario
> > > > FROM Vehiculos
> > > > WHERE ' aqui la condición que depende de los campos que

seleccione

> el
> > > > usuario
> > > >
> > > > gracias
> > > >
> > > >
> > > >
> > > > Diego
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Maxi, si necesitas un sitio donde publicarlo, tienes helpdna.net a tu
disposición ;-)

Un saludo
Salvador Ramos
Murcia - España
[Microsoft MVP SQL Server]
www.helpdna.net (información sobre SQL server, Windows DNA y .NET)

"Maxi" escribió en el mensaje
news:

Hola, te comento:

Hacer un Sp's generico para todos los campos de una entidad no lleva mas
de 5' y no son muchas lineas.

Te comento un truco (no deberia pero bue.. ;), un ERP conocido ha
solucionado este problema de la siguiente forma:

Tiene 2 Sp's para consultas genericas (uno con OR y el otro con AND), que
hace basicamente?

En el del or estan todos los campos seguidos por OR y en el de AND igual.
En la aplicacion tienen una pantalla de busqueda generica, donde el
usuario final selecciona entre usar el metodo AND o el metodo OR.

Bien, te comento, este ERP tiene mas de 5.000 clientes en todo el mundo, y
empresas muy criticas, y este metodo lo tienen implementado desde hace 5
años, como funciona? de mil maravillas, los usuarios generalmente con esta
funcionalidad cumplen el 99% de los casos. Las cosas muy pero muy
especificas las resolvera alguien del depto de sistemas, o a lo sumo
podras hacer un modulo de generacion de querys donde lo que haga es armar
un Sp's.

Hacer estas cosas no demora nada en el desarrollo, el tema es que hay que
tener la tecnica y la habilidad, porque si te vas a poner a escribir campo
a campo estas frita!! hay herramientas gratuitas que hacen la tarea por
vos, o tambien algunos trucos de T-sql que con un par de lineas podrias
generar todo el codigo que necesitas.

Voy a ver si escribo un articulo sobre este tema asi se dan cuenta de lo
que digo :-)




Salu2
Maxi


"Danilsa" escribió en el mensaje
news:

Disculpen la intromision pero mira, yo he usado Delphi por mucho tiempo
con
distintas bases de datos (firebird, oracle, sql server incluido) y uno
siempre acostumbra a poner alguna opcion especial para buscar por muchos
tipos de columnas que no estan pre concebidos en el diseño del sistema.
Eso
para los programadores de aplicaciones es algo muy normal. Si fuera a
tener
que hacer un store proc para cada posible combinacion de columnas y
wheres,
order by, etc. pues sin exagerar saldrian cerca de 1000 !!! y si por el
contrario decido hacer un solo procedimiento pues la cantidad de lineas y
condicionales que este tendria seria virtualmente imposible de
programarlo.
Mientras mas campos tengan las tablas en cuestion es peor aun.

El riesgo de la inyeccion de codigo para mi es menor contra el trabajo
que
supone hacer eso y uno solo le da permiso a las tablas especificas al
usuario. Y tambien pienso que esa inyeccion no puede ocurrir en la
aplicacion que tiene su propio espacio de memoria si no solo cuando
tienes
la generacion dinamica en el propio sP, aunque me sorprendo de que digas
que
si ocurre en la aplicacion. Donde puedo obtener mas informacion sobre
inyeccion de codigo en la aplicacion cliente ? Me podrias dar un link
sobre
ese tema ?

Finalmente, tengo sistemas de años y siempre he usado este método para
esas
consultas especiales y la verdad nunca he visto por una parte problemas
de
seguridad ni de rendimiento pues como dice como dice el compañero se
supone
que no son transacciones de uso intensivo.




"Patrick Mac Kay" <pmackay_at_hotmail.com> wrote in message
news:%

Ricardo,

el sql injection se produce por el armado de sql dinamicamente, ya
sea
en el sp o en tu programa. Y respondiento a tu pregunta, si, hago todo

con

SPs, que no son dinámicos. Todo armado y precompilado. Todos los

excecution

plans revisados y depurados al máximo. Todas las consultas optimizadas y

los

indices creados en las tablas, ya sean clustered o no. Además, con sps
minimizas el manejo de permisos en la base de datos, o tu le das todos
los
permisos a todas las tablas para el usuario con que te logeas? o lo
dejas
como dueño de la base de datos?

Es exactamente esa complejidad que estas programando en la consulta la
que
hará que el sqlserver pueda obtener los mejores caminos de ejecución. Si

el

sql cambia a cada rato, los caminos no serán los optimos.

Si cambias los datos, cambias el sp, eso es obvio, pero no tocas la
funcionalidad de tu programa. Son ajustes menores. Es la base de
cualquier
desarrolo en capas.

No es ser sp maniaco. Es obtener el mejor resultado de tu servidor de

datos.

Patrick.

"Ricardo" escribió en el mensaje
news:
>
> "Patrick Mac Kay" <pmackay_at_hotmail.com> escribió en el mensaje
> news:
> > Ricardo,
> >
> > por que si armas un select en tu aplicación tienes los siguintes
> > problemas.
> >
> > 1.- Sql Injection (alta probabilidad)
>
> No hablo de sql dinamico en el sp sino generar la instruccion select
> en

la

> aplicacion ANTES de postearlo al servidor. El riesgo no es mayor que
cuando
> envies un simple select * from directamente sin tenerlo en SP. O tu
> lo
> haces absolutamente todo con SP ? incluso un simple 'select * from

tabla'

de
> una tabla pequeña ? dependiendo del lenguaje que uses puede ser que
> lo
> estes haciendo sin darte cuenta siquiera. Ese es un tema discutible.
>
> > 2.- No es compilado por el sql, y por lo tanto no puede definir la

mejor

> > ruta de ejecución, algo que para los reportes es vital.
>
> Todo depende de la frecuencia de uso. No todo tiene porque estar
> pre-compilado, sencillamente porque no todo esta previsto en una
aplicacion.
> El habla practicamente de una consulta AD-HOC que si entendi bien,
> las
> combinaciones que genere para meterla en un SP lo harian sumamente
complejo
> de programar.
>
> >
> > 3.- Complicas el desarrollo por que si cambias algo en tu base de

datos

> > debes tocar el codigo.
> >
>
> Puede ser pero si cambio algo en la base de datos tambien tendre que
"tocar"
> el codigo del SP fijo que recomiendas. Casi es lo mismo. Mas aun la
> aplicacion puede programarse de modo generico sin necesidad de código
"duro"
> como lo es el SP fijo que recomiendas.
>
> >
> > La forma correcta es hacer un SP y seguir lo que te mencionó Maxi de

los

> > isnull.
> >
>
> Los SP's son importantisimos estoy de acuerdo. Yo los uso para la

mayoría

de
> las cosas. Pero "no todo en la vida son SP's". Maxi tiene mucho
fundamento
> en lo que dice pero hay que decir que es "SP maníaco". Hay algunos

casos

> (pocos insisto) donde no hay que ser tan rígido. Todo depende de la
> frecuencia del query y del caso particular que se trate (el cual no lo

sé

> realmente). Ademas no estamos hablando aqui de modificaciones sino de
> consultas.
>
>
> > saludos.
> >
> > Patrick.
> >
> > "Ricardo Passians" escribió en el
> > mensaje
> > news:
> > > Y porque en vez de un procedimiento, mejor armas el select desde
> > > tu
> > > aplicación ?
> > > Hay casos (pocos si) donde no es practico tenerlo en un sp. Ahora
bien,
> > si
> > > insistes en ponerlo en un SP deberas manejar en el todas las
> combinaciones
> > > posibles y te convendrias hacer un script tambien desde tu sistema

que

> te
> > > genere el codigo del SP a un archivo, lo cortas y lo pegas en un
create
> > proc
> > > en el query analizer o enterprise manager.
> > >
> > > "Romero Diego" wrote in message
> > > news:%
> > > > Hola
> > > > Todos
> > > >
> > > > Tengo un problema :
> > > > La tabla que describo a continuación tiene muchos campos y tengo

que

> > hacer
> > > > un reporte donde en una lista esten los nombres de los campos y
> > > > el
> > usuario
> > > > seleccione los que desee filtrar, esto se hace desde VB
> > > >
> > > > El problema es como hago un procedimiento almacenado para
> > > > paserle
los
> > > > parametros segun los campos que seleccione o necesariamente debo
crear
> > > > parametro por campo ?
> > > >
> > > > SELECT IdVehiculo, Numero, IdClase, IdMarca, IdLinea,
> > > > IdColor,
> > > IdTipoVeh,
> > > > IdTipoMot, AnnoModelo, FecRepotencia, Ejes, NumLlantas, PesoVeh,
> > > Pasajeros,
> > > > PasajPie, CapTanque, NumeroMotor,

SerieChasis,

> > > > Cilindrada, IdTipoCom, IdTipoLla, IdTipoLub, IdMarLla, IdMarLub,
> > > IdEmpresa,
> > > > IdPropietario,
> > > > IdConductor, IdTipoPro,
> > > Adquisicion,IdGrupo,VehPropio,
> > > > IdProveedor, FecCompra, TarjetaProp, CostoCompra, ValorAvaludo,
> > > > ValorAsegurado,ValorCupo, IdAdmon,
> > > > NumContrato,ContratoActivo,FecIngreso,
> > > > FecRetiro,FecVigencia,FecSalida, VidaUtil, FecImpuestos,
DocCompleta,
> > > > Accidentes,ObligaTProd, PolizaSoat,FecSoat,VigSoat,EmpresaSoat
> > > >
> > ,GarantiaAcc,PolizaResCivil,FecResCivil,VigResCivil,
> > > > CertMovilizacion, FecCertMovil, VigCertMovil, TarjetaOperacion,
> > > FecTarjOper,
> > > > VigTarjOper, CertGases, FecCertGases, VigCertGases,
> > > > Kilometraje, KmsCompra,
> > > > Observacion,CentInicial,CentFinal,CupoCredito,SaldoActual,
> ArchivoFoto,
> > > > IdEstado, FechaAdd, FechaUpdate, IdUsuario
> > > > FROM Vehiculos
> > > > WHERE ' aqui la condición que depende de los campos que

seleccione

> el
> > > > usuario
> > > >
> > > > gracias
> > > >
> > > >
> > > >
> > > > Diego
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Hola, sin dudarlo :-), voy a ver si cuando vengo de las vacaciones lo armo y
te lo paso via Pbox :-)

Gracias amigo


Salu2
Maxi


"Salvador Ramos" escribió en el
mensaje news:

Maxi, si necesitas un sitio donde publicarlo, tienes helpdna.net a tu
disposición ;-)

Un saludo
Salvador Ramos
Murcia - España
[Microsoft MVP SQL Server]
www.helpdna.net (información sobre SQL server, Windows DNA y .NET)

"Maxi" escribió en el mensaje
news:

Hola, te comento:

Hacer un Sp's generico para todos los campos de una entidad no lleva mas
de 5' y no son muchas lineas.

Te comento un truco (no deberia pero bue.. ;), un ERP conocido ha
solucionado este problema de la siguiente forma:

Tiene 2 Sp's para consultas genericas (uno con OR y el otro con AND), que
hace basicamente?

En el del or estan todos los campos seguidos por OR y en el de AND igual.
En la aplicacion tienen una pantalla de busqueda generica, donde el
usuario final selecciona entre usar el metodo AND o el metodo OR.

Bien, te comento, este ERP tiene mas de 5.000 clientes en todo el mundo,
y empresas muy criticas, y este metodo lo tienen implementado desde hace
5 años, como funciona? de mil maravillas, los usuarios generalmente con
esta funcionalidad cumplen el 99% de los casos. Las cosas muy pero muy
especificas las resolvera alguien del depto de sistemas, o a lo sumo
podras hacer un modulo de generacion de querys donde lo que haga es armar
un Sp's.

Hacer estas cosas no demora nada en el desarrollo, el tema es que hay que
tener la tecnica y la habilidad, porque si te vas a poner a escribir
campo a campo estas frita!! hay herramientas gratuitas que hacen la tarea
por vos, o tambien algunos trucos de T-sql que con un par de lineas
podrias generar todo el codigo que necesitas.

Voy a ver si escribo un articulo sobre este tema asi se dan cuenta de lo
que digo :-)




Salu2
Maxi


"Danilsa" escribió en el mensaje
news:

Disculpen la intromision pero mira, yo he usado Delphi por mucho tiempo
con
distintas bases de datos (firebird, oracle, sql server incluido) y uno
siempre acostumbra a poner alguna opcion especial para buscar por muchos
tipos de columnas que no estan pre concebidos en el diseño del sistema.
Eso
para los programadores de aplicaciones es algo muy normal. Si fuera a
tener
que hacer un store proc para cada posible combinacion de columnas y
wheres,
order by, etc. pues sin exagerar saldrian cerca de 1000 !!! y si por el
contrario decido hacer un solo procedimiento pues la cantidad de lineas
y
condicionales que este tendria seria virtualmente imposible de
programarlo.
Mientras mas campos tengan las tablas en cuestion es peor aun.

El riesgo de la inyeccion de codigo para mi es menor contra el trabajo
que
supone hacer eso y uno solo le da permiso a las tablas especificas al
usuario. Y tambien pienso que esa inyeccion no puede ocurrir en la
aplicacion que tiene su propio espacio de memoria si no solo cuando
tienes
la generacion dinamica en el propio sP, aunque me sorprendo de que digas
que
si ocurre en la aplicacion. Donde puedo obtener mas informacion sobre
inyeccion de codigo en la aplicacion cliente ? Me podrias dar un link
sobre
ese tema ?

Finalmente, tengo sistemas de años y siempre he usado este método para
esas
consultas especiales y la verdad nunca he visto por una parte problemas
de
seguridad ni de rendimiento pues como dice como dice el compañero se
supone
que no son transacciones de uso intensivo.




"Patrick Mac Kay" <pmackay_at_hotmail.com> wrote in message
news:%

Ricardo,

el sql injection se produce por el armado de sql dinamicamente, ya
sea
en el sp o en tu programa. Y respondiento a tu pregunta, si, hago todo

con

SPs, que no son dinámicos. Todo armado y precompilado. Todos los

excecution

plans revisados y depurados al máximo. Todas las consultas optimizadas
y

los

indices creados en las tablas, ya sean clustered o no. Además, con sps
minimizas el manejo de permisos en la base de datos, o tu le das todos
los
permisos a todas las tablas para el usuario con que te logeas? o lo
dejas
como dueño de la base de datos?

Es exactamente esa complejidad que estas programando en la consulta la
que
hará que el sqlserver pueda obtener los mejores caminos de ejecución.
Si

el

sql cambia a cada rato, los caminos no serán los optimos.

Si cambias los datos, cambias el sp, eso es obvio, pero no tocas la
funcionalidad de tu programa. Son ajustes menores. Es la base de
cualquier
desarrolo en capas.

No es ser sp maniaco. Es obtener el mejor resultado de tu servidor de

datos.

Patrick.

"Ricardo" escribió en el mensaje
news:
>
> "Patrick Mac Kay" <pmackay_at_hotmail.com> escribió en el mensaje
> news:
> > Ricardo,
> >
> > por que si armas un select en tu aplicación tienes los
> > siguintes
> > problemas.
> >
> > 1.- Sql Injection (alta probabilidad)
>
> No hablo de sql dinamico en el sp sino generar la instruccion select
> en

la

> aplicacion ANTES de postearlo al servidor. El riesgo no es mayor que
cuando
> envies un simple select * from directamente sin tenerlo en SP. O tu
> lo
> haces absolutamente todo con SP ? incluso un simple 'select * from

tabla'

de
> una tabla pequeña ? dependiendo del lenguaje que uses puede ser que
> lo
> estes haciendo sin darte cuenta siquiera. Ese es un tema discutible.
>
> > 2.- No es compilado por el sql, y por lo tanto no puede definir la

mejor

> > ruta de ejecución, algo que para los reportes es vital.
>
> Todo depende de la frecuencia de uso. No todo tiene porque estar
> pre-compilado, sencillamente porque no todo esta previsto en una
aplicacion.
> El habla practicamente de una consulta AD-HOC que si entendi bien,
> las
> combinaciones que genere para meterla en un SP lo harian sumamente
complejo
> de programar.
>
> >
> > 3.- Complicas el desarrollo por que si cambias algo en tu base de

datos

> > debes tocar el codigo.
> >
>
> Puede ser pero si cambio algo en la base de datos tambien tendre que
"tocar"
> el codigo del SP fijo que recomiendas. Casi es lo mismo. Mas aun la
> aplicacion puede programarse de modo generico sin necesidad de código
"duro"
> como lo es el SP fijo que recomiendas.
>
> >
> > La forma correcta es hacer un SP y seguir lo que te mencionó Maxi
> > de

los

> > isnull.
> >
>
> Los SP's son importantisimos estoy de acuerdo. Yo los uso para la

mayoría

de
> las cosas. Pero "no todo en la vida son SP's". Maxi tiene mucho
fundamento
> en lo que dice pero hay que decir que es "SP maníaco". Hay algunos

casos

> (pocos insisto) donde no hay que ser tan rígido. Todo depende de la
> frecuencia del query y del caso particular que se trate (el cual no
> lo

sé

> realmente). Ademas no estamos hablando aqui de modificaciones sino
> de
> consultas.
>
>
> > saludos.
> >
> > Patrick.
> >
> > "Ricardo Passians" escribió en el
> > mensaje
> > news:
> > > Y porque en vez de un procedimiento, mejor armas el select desde
> > > tu
> > > aplicación ?
> > > Hay casos (pocos si) donde no es practico tenerlo en un sp.
> > > Ahora
bien,
> > si
> > > insistes en ponerlo en un SP deberas manejar en el todas las
> combinaciones
> > > posibles y te convendrias hacer un script tambien desde tu
> > > sistema

que

> te
> > > genere el codigo del SP a un archivo, lo cortas y lo pegas en un
create
> > proc
> > > en el query analizer o enterprise manager.
> > >
> > > "Romero Diego" wrote in message
> > > news:%
> > > > Hola
> > > > Todos
> > > >
> > > > Tengo un problema :
> > > > La tabla que describo a continuación tiene muchos campos y
> > > > tengo

que

> > hacer
> > > > un reporte donde en una lista esten los nombres de los campos y
> > > > el
> > usuario
> > > > seleccione los que desee filtrar, esto se hace desde VB
> > > >
> > > > El problema es como hago un procedimiento almacenado para
> > > > paserle
los
> > > > parametros segun los campos que seleccione o necesariamente
> > > > debo
crear
> > > > parametro por campo ?
> > > >
> > > > SELECT IdVehiculo, Numero, IdClase, IdMarca, IdLinea,
> > > > IdColor,
> > > IdTipoVeh,
> > > > IdTipoMot, AnnoModelo, FecRepotencia, Ejes, NumLlantas,
> > > > PesoVeh,
> > > Pasajeros,
> > > > PasajPie, CapTanque, NumeroMotor,

SerieChasis,

> > > > Cilindrada, IdTipoCom, IdTipoLla, IdTipoLub, IdMarLla,
> > > > IdMarLub,
> > > IdEmpresa,
> > > > IdPropietario,
> > > > IdConductor, IdTipoPro,
> > > Adquisicion,IdGrupo,VehPropio,
> > > > IdProveedor, FecCompra, TarjetaProp, CostoCompra, ValorAvaludo,
> > > > ValorAsegurado,ValorCupo, IdAdmon,
> > > > NumContrato,ContratoActivo,FecIngreso,
> > > > FecRetiro,FecVigencia,FecSalida, VidaUtil, FecImpuestos,
DocCompleta,
> > > > Accidentes,ObligaTProd, PolizaSoat,FecSoat,VigSoat,EmpresaSoat
> > > >
> > ,GarantiaAcc,PolizaResCivil,FecResCivil,VigResCivil,
> > > > CertMovilizacion, FecCertMovil, VigCertMovil, TarjetaOperacion,
> > > FecTarjOper,
> > > > VigTarjOper, CertGases, FecCertGases, VigCertGases,
> > > > Kilometraje, KmsCompra,
> > > > Observacion,CentInicial,CentFinal,CupoCredito,SaldoActual,
> ArchivoFoto,
> > > > IdEstado, FechaAdd, FechaUpdate, IdUsuario
> > > > FROM Vehiculos
> > > > WHERE ' aqui la condición que depende de los campos que

seleccione

> el
> > > > usuario
> > > >
> > > > gracias
> > > >
> > > >
> > > >
> > > > Diego
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

De momento no tengo implementada la inclusión de artículos mediante Pbox :-(
Es una tarea pendiente, a ver si saco unas horas libres y lo pongo en
marcha.

Me lo puedes enviar por email, y yo lo publico.

Un saludo
Salvador Ramos
Murcia - España
[Microsoft MVP SQL Server]
www.helpdna.net (información sobre SQL server, Windows DNA y .NET)

"Maxi" escribió en el mensaje
news:%

Hola, sin dudarlo :-), voy a ver si cuando vengo de las vacaciones lo armo
y te lo paso via Pbox :-)

Gracias amigo


Salu2
Maxi


"Salvador Ramos" escribió en el
mensaje news:

Maxi, si necesitas un sitio donde publicarlo, tienes helpdna.net a tu
disposición ;-)

Un saludo
Salvador Ramos
Murcia - España
[Microsoft MVP SQL Server]
www.helpdna.net (información sobre SQL server, Windows DNA y .NET)

"Maxi" escribió en el mensaje
news:

Hola, te comento:

Hacer un Sp's generico para todos los campos de una entidad no lleva mas
de 5' y no son muchas lineas.

Te comento un truco (no deberia pero bue.. ;), un ERP conocido ha
solucionado este problema de la siguiente forma:

Tiene 2 Sp's para consultas genericas (uno con OR y el otro con AND),
que hace basicamente?

En el del or estan todos los campos seguidos por OR y en el de AND
igual. En la aplicacion tienen una pantalla de busqueda generica, donde
el usuario final selecciona entre usar el metodo AND o el metodo OR.

Bien, te comento, este ERP tiene mas de 5.000 clientes en todo el mundo,
y empresas muy criticas, y este metodo lo tienen implementado desde hace
5 años, como funciona? de mil maravillas, los usuarios generalmente con
esta funcionalidad cumplen el 99% de los casos. Las cosas muy pero muy
especificas las resolvera alguien del depto de sistemas, o a lo sumo
podras hacer un modulo de generacion de querys donde lo que haga es
armar un Sp's.

Hacer estas cosas no demora nada en el desarrollo, el tema es que hay
que tener la tecnica y la habilidad, porque si te vas a poner a escribir
campo a campo estas frita!! hay herramientas gratuitas que hacen la
tarea por vos, o tambien algunos trucos de T-sql que con un par de
lineas podrias generar todo el codigo que necesitas.

Voy a ver si escribo un articulo sobre este tema asi se dan cuenta de lo
que digo :-)




Salu2
Maxi


"Danilsa" escribió en el mensaje
news:

Disculpen la intromision pero mira, yo he usado Delphi por mucho tiempo
con
distintas bases de datos (firebird, oracle, sql server incluido) y uno
siempre acostumbra a poner alguna opcion especial para buscar por
muchos
tipos de columnas que no estan pre concebidos en el diseño del sistema.
Eso
para los programadores de aplicaciones es algo muy normal. Si fuera a
tener
que hacer un store proc para cada posible combinacion de columnas y
wheres,
order by, etc. pues sin exagerar saldrian cerca de 1000 !!! y si por el
contrario decido hacer un solo procedimiento pues la cantidad de lineas
y
condicionales que este tendria seria virtualmente imposible de
programarlo.
Mientras mas campos tengan las tablas en cuestion es peor aun.

El riesgo de la inyeccion de codigo para mi es menor contra el trabajo
que
supone hacer eso y uno solo le da permiso a las tablas especificas al
usuario. Y tambien pienso que esa inyeccion no puede ocurrir en la
aplicacion que tiene su propio espacio de memoria si no solo cuando
tienes
la generacion dinamica en el propio sP, aunque me sorprendo de que
digas que
si ocurre en la aplicacion. Donde puedo obtener mas informacion sobre
inyeccion de codigo en la aplicacion cliente ? Me podrias dar un link
sobre
ese tema ?

Finalmente, tengo sistemas de años y siempre he usado este método para
esas
consultas especiales y la verdad nunca he visto por una parte problemas
de
seguridad ni de rendimiento pues como dice como dice el compañero se
supone
que no son transacciones de uso intensivo.




"Patrick Mac Kay" <pmackay_at_hotmail.com> wrote in message
news:%

Ricardo,

el sql injection se produce por el armado de sql dinamicamente, ya
sea
en el sp o en tu programa. Y respondiento a tu pregunta, si, hago
todo

con

SPs, que no son dinámicos. Todo armado y precompilado. Todos los

excecution

plans revisados y depurados al máximo. Todas las consultas optimizadas
y

los

indices creados en las tablas, ya sean clustered o no. Además, con sps
minimizas el manejo de permisos en la base de datos, o tu le das todos
los
permisos a todas las tablas para el usuario con que te logeas? o lo
dejas
como dueño de la base de datos?

Es exactamente esa complejidad que estas programando en la consulta la
que
hará que el sqlserver pueda obtener los mejores caminos de ejecución.
Si

el

sql cambia a cada rato, los caminos no serán los optimos.

Si cambias los datos, cambias el sp, eso es obvio, pero no tocas la
funcionalidad de tu programa. Son ajustes menores. Es la base de
cualquier
desarrolo en capas.

No es ser sp maniaco. Es obtener el mejor resultado de tu servidor de

datos.

Patrick.

"Ricardo" escribió en el mensaje
news:
>
> "Patrick Mac Kay" <pmackay_at_hotmail.com> escribió en el mensaje
> news:
> > Ricardo,
> >
> > por que si armas un select en tu aplicación tienes los
> > siguintes
> > problemas.
> >
> > 1.- Sql Injection (alta probabilidad)
>
> No hablo de sql dinamico en el sp sino generar la instruccion select
> en

la

> aplicacion ANTES de postearlo al servidor. El riesgo no es mayor
> que
cuando
> envies un simple select * from directamente sin tenerlo en SP. O tu
> lo
> haces absolutamente todo con SP ? incluso un simple 'select * from

tabla'

de
> una tabla pequeña ? dependiendo del lenguaje que uses puede ser
> que lo
> estes haciendo sin darte cuenta siquiera. Ese es un tema
> discutible.
>
> > 2.- No es compilado por el sql, y por lo tanto no puede definir la

mejor

> > ruta de ejecución, algo que para los reportes es vital.
>
> Todo depende de la frecuencia de uso. No todo tiene porque estar
> pre-compilado, sencillamente porque no todo esta previsto en una
aplicacion.
> El habla practicamente de una consulta AD-HOC que si entendi bien,
> las
> combinaciones que genere para meterla en un SP lo harian sumamente
complejo
> de programar.
>
> >
> > 3.- Complicas el desarrollo por que si cambias algo en tu base de

datos

> > debes tocar el codigo.
> >
>
> Puede ser pero si cambio algo en la base de datos tambien tendre que
"tocar"
> el codigo del SP fijo que recomiendas. Casi es lo mismo. Mas aun la
> aplicacion puede programarse de modo generico sin necesidad de
> código
"duro"
> como lo es el SP fijo que recomiendas.
>
> >
> > La forma correcta es hacer un SP y seguir lo que te mencionó Maxi
> > de

los

> > isnull.
> >
>
> Los SP's son importantisimos estoy de acuerdo. Yo los uso para la

mayoría

de
> las cosas. Pero "no todo en la vida son SP's". Maxi tiene mucho
fundamento
> en lo que dice pero hay que decir que es "SP maníaco". Hay algunos

casos

> (pocos insisto) donde no hay que ser tan rígido. Todo depende de la
> frecuencia del query y del caso particular que se trate (el cual no
> lo

sé

> realmente). Ademas no estamos hablando aqui de modificaciones sino
> de
> consultas.
>
>
> > saludos.
> >
> > Patrick.
> >
> > "Ricardo Passians" escribió en el
> > mensaje
> > news:
> > > Y porque en vez de un procedimiento, mejor armas el select desde
> > > tu
> > > aplicación ?
> > > Hay casos (pocos si) donde no es practico tenerlo en un sp.
> > > Ahora
bien,
> > si
> > > insistes en ponerlo en un SP deberas manejar en el todas las
> combinaciones
> > > posibles y te convendrias hacer un script tambien desde tu
> > > sistema

que

> te
> > > genere el codigo del SP a un archivo, lo cortas y lo pegas en un
create
> > proc
> > > en el query analizer o enterprise manager.
> > >
> > > "Romero Diego" wrote in message
> > > news:%
> > > > Hola
> > > > Todos
> > > >
> > > > Tengo un problema :
> > > > La tabla que describo a continuación tiene muchos campos y
> > > > tengo

que

> > hacer
> > > > un reporte donde en una lista esten los nombres de los campos
> > > > y el
> > usuario
> > > > seleccione los que desee filtrar, esto se hace desde VB
> > > >
> > > > El problema es como hago un procedimiento almacenado para
> > > > paserle
los
> > > > parametros segun los campos que seleccione o necesariamente
> > > > debo
crear
> > > > parametro por campo ?
> > > >
> > > > SELECT IdVehiculo, Numero, IdClase, IdMarca, IdLinea,
> > > > IdColor,
> > > IdTipoVeh,
> > > > IdTipoMot, AnnoModelo, FecRepotencia, Ejes, NumLlantas,
> > > > PesoVeh,
> > > Pasajeros,
> > > > PasajPie, CapTanque, NumeroMotor,

SerieChasis,

> > > > Cilindrada, IdTipoCom, IdTipoLla, IdTipoLub, IdMarLla,
> > > > IdMarLub,
> > > IdEmpresa,
> > > > IdPropietario,
> > > > IdConductor, IdTipoPro,
> > > Adquisicion,IdGrupo,VehPropio,
> > > > IdProveedor, FecCompra, TarjetaProp, CostoCompra,
> > > > ValorAvaludo,
> > > > ValorAsegurado,ValorCupo, IdAdmon,
> > > > NumContrato,ContratoActivo,FecIngreso,
> > > > FecRetiro,FecVigencia,FecSalida, VidaUtil, FecImpuestos,
DocCompleta,
> > > > Accidentes,ObligaTProd, PolizaSoat,FecSoat,VigSoat,EmpresaSoat
> > > >
> > ,GarantiaAcc,PolizaResCivil,FecResCivil,VigResCivil,
> > > > CertMovilizacion, FecCertMovil, VigCertMovil,
> > > > TarjetaOperacion,
> > > FecTarjOper,
> > > > VigTarjOper, CertGases, FecCertGases, VigCertGases,
> > > > Kilometraje, KmsCompra,
> > > > Observacion,CentInicial,CentFinal,CupoCredito,SaldoActual,
> ArchivoFoto,
> > > > IdEstado, FechaAdd, FechaUpdate, IdUsuario
> > > > FROM Vehiculos
> > > > WHERE ' aqui la condición que depende de los campos que

seleccione

> el
> > > > usuario
> > > >
> > > > gracias
> > > >
> > > >
> > > >
> > > > Diego
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

ok, no te hagas drama, yo lo armo y te lo paso :-)


Salu2
Maxi


"Salvador Ramos" escribió en el
mensaje news:%

De momento no tengo implementada la inclusión de artículos mediante Pbox
:-(
Es una tarea pendiente, a ver si saco unas horas libres y lo pongo en
marcha.

Me lo puedes enviar por email, y yo lo publico.

Un saludo
Salvador Ramos
Murcia - España
[Microsoft MVP SQL Server]
www.helpdna.net (información sobre SQL server, Windows DNA y .NET)

"Maxi" escribió en el mensaje
news:%

Hola, sin dudarlo :-), voy a ver si cuando vengo de las vacaciones lo
armo y te lo paso via Pbox :-)

Gracias amigo


Salu2
Maxi


"Salvador Ramos" escribió en el
mensaje news:

Maxi, si necesitas un sitio donde publicarlo, tienes helpdna.net a tu
disposición ;-)

Un saludo
Salvador Ramos
Murcia - España
[Microsoft MVP SQL Server]
www.helpdna.net (información sobre SQL server, Windows DNA y .NET)

"Maxi" escribió en el mensaje
news:

Hola, te comento:

Hacer un Sp's generico para todos los campos de una entidad no lleva
mas de 5' y no son muchas lineas.

Te comento un truco (no deberia pero bue.. ;), un ERP conocido ha
solucionado este problema de la siguiente forma:

Tiene 2 Sp's para consultas genericas (uno con OR y el otro con AND),
que hace basicamente?

En el del or estan todos los campos seguidos por OR y en el de AND
igual. En la aplicacion tienen una pantalla de busqueda generica, donde
el usuario final selecciona entre usar el metodo AND o el metodo OR.

Bien, te comento, este ERP tiene mas de 5.000 clientes en todo el
mundo, y empresas muy criticas, y este metodo lo tienen implementado
desde hace 5 años, como funciona? de mil maravillas, los usuarios
generalmente con esta funcionalidad cumplen el 99% de los casos. Las
cosas muy pero muy especificas las resolvera alguien del depto de
sistemas, o a lo sumo podras hacer un modulo de generacion de querys
donde lo que haga es armar un Sp's.

Hacer estas cosas no demora nada en el desarrollo, el tema es que hay
que tener la tecnica y la habilidad, porque si te vas a poner a
escribir campo a campo estas frita!! hay herramientas gratuitas que
hacen la tarea por vos, o tambien algunos trucos de T-sql que con un
par de lineas podrias generar todo el codigo que necesitas.

Voy a ver si escribo un articulo sobre este tema asi se dan cuenta de
lo que digo :-)




Salu2
Maxi


"Danilsa" escribió en el mensaje
news:

Disculpen la intromision pero mira, yo he usado Delphi por mucho
tiempo con
distintas bases de datos (firebird, oracle, sql server incluido) y uno
siempre acostumbra a poner alguna opcion especial para buscar por
muchos
tipos de columnas que no estan pre concebidos en el diseño del
sistema. Eso
para los programadores de aplicaciones es algo muy normal. Si fuera a
tener
que hacer un store proc para cada posible combinacion de columnas y
wheres,
order by, etc. pues sin exagerar saldrian cerca de 1000 !!! y si por
el
contrario decido hacer un solo procedimiento pues la cantidad de
lineas y
condicionales que este tendria seria virtualmente imposible de
programarlo.
Mientras mas campos tengan las tablas en cuestion es peor aun.

El riesgo de la inyeccion de codigo para mi es menor contra el trabajo
que
supone hacer eso y uno solo le da permiso a las tablas especificas al
usuario. Y tambien pienso que esa inyeccion no puede ocurrir en la
aplicacion que tiene su propio espacio de memoria si no solo cuando
tienes
la generacion dinamica en el propio sP, aunque me sorprendo de que
digas que
si ocurre en la aplicacion. Donde puedo obtener mas informacion sobre
inyeccion de codigo en la aplicacion cliente ? Me podrias dar un link
sobre
ese tema ?

Finalmente, tengo sistemas de años y siempre he usado este método para
esas
consultas especiales y la verdad nunca he visto por una parte
problemas de
seguridad ni de rendimiento pues como dice como dice el compañero se
supone
que no son transacciones de uso intensivo.




"Patrick Mac Kay" <pmackay_at_hotmail.com> wrote in message
news:%

Ricardo,

el sql injection se produce por el armado de sql dinamicamente,
ya sea
en el sp o en tu programa. Y respondiento a tu pregunta, si, hago
todo

con

SPs, que no son dinámicos. Todo armado y precompilado. Todos los

excecution

plans revisados y depurados al máximo. Todas las consultas
optimizadas y

los

indices creados en las tablas, ya sean clustered o no. Además, con
sps
minimizas el manejo de permisos en la base de datos, o tu le das
todos los
permisos a todas las tablas para el usuario con que te logeas? o lo
dejas
como dueño de la base de datos?

Es exactamente esa complejidad que estas programando en la consulta
la que
hará que el sqlserver pueda obtener los mejores caminos de ejecución.
Si

el

sql cambia a cada rato, los caminos no serán los optimos.

Si cambias los datos, cambias el sp, eso es obvio, pero no tocas la
funcionalidad de tu programa. Son ajustes menores. Es la base de
cualquier
desarrolo en capas.

No es ser sp maniaco. Es obtener el mejor resultado de tu servidor de

datos.

Patrick.

"Ricardo" escribió en el mensaje
news:
>
> "Patrick Mac Kay" <pmackay_at_hotmail.com> escribió en el mensaje
> news:
> > Ricardo,
> >
> > por que si armas un select en tu aplicación tienes los
> > siguintes
> > problemas.
> >
> > 1.- Sql Injection (alta probabilidad)
>
> No hablo de sql dinamico en el sp sino generar la instruccion
> select en

la

> aplicacion ANTES de postearlo al servidor. El riesgo no es mayor
> que
cuando
> envies un simple select * from directamente sin tenerlo en SP. O
> tu lo
> haces absolutamente todo con SP ? incluso un simple 'select * from

tabla'

de
> una tabla pequeña ? dependiendo del lenguaje que uses puede ser
> que lo
> estes haciendo sin darte cuenta siquiera. Ese es un tema
> discutible.
>
> > 2.- No es compilado por el sql, y por lo tanto no puede definir
> > la

mejor

> > ruta de ejecución, algo que para los reportes es vital.
>
> Todo depende de la frecuencia de uso. No todo tiene porque estar
> pre-compilado, sencillamente porque no todo esta previsto en una
aplicacion.
> El habla practicamente de una consulta AD-HOC que si entendi bien,
> las
> combinaciones que genere para meterla en un SP lo harian sumamente
complejo
> de programar.
>
> >
> > 3.- Complicas el desarrollo por que si cambias algo en tu base de

datos

> > debes tocar el codigo.
> >
>
> Puede ser pero si cambio algo en la base de datos tambien tendre
> que
"tocar"
> el codigo del SP fijo que recomiendas. Casi es lo mismo. Mas aun
> la
> aplicacion puede programarse de modo generico sin necesidad de
> código
"duro"
> como lo es el SP fijo que recomiendas.
>
> >
> > La forma correcta es hacer un SP y seguir lo que te mencionó Maxi
> > de

los

> > isnull.
> >
>
> Los SP's son importantisimos estoy de acuerdo. Yo los uso para la

mayoría

de
> las cosas. Pero "no todo en la vida son SP's". Maxi tiene mucho
fundamento
> en lo que dice pero hay que decir que es "SP maníaco". Hay algunos

casos

> (pocos insisto) donde no hay que ser tan rígido. Todo depende de
> la
> frecuencia del query y del caso particular que se trate (el cual no
> lo

sé

> realmente). Ademas no estamos hablando aqui de modificaciones sino
> de
> consultas.
>
>
> > saludos.
> >
> > Patrick.
> >
> > "Ricardo Passians" escribió en el
> > mensaje
> > news:
> > > Y porque en vez de un procedimiento, mejor armas el select
> > > desde tu
> > > aplicación ?
> > > Hay casos (pocos si) donde no es practico tenerlo en un sp.
> > > Ahora
bien,
> > si
> > > insistes en ponerlo en un SP deberas manejar en el todas las
> combinaciones
> > > posibles y te convendrias hacer un script tambien desde tu
> > > sistema

que

> te
> > > genere el codigo del SP a un archivo, lo cortas y lo pegas en
> > > un
create
> > proc
> > > en el query analizer o enterprise manager.
> > >
> > > "Romero Diego" wrote in message
> > > news:%
> > > > Hola
> > > > Todos
> > > >
> > > > Tengo un problema :
> > > > La tabla que describo a continuación tiene muchos campos y
> > > > tengo

que

> > hacer
> > > > un reporte donde en una lista esten los nombres de los campos
> > > > y el
> > usuario
> > > > seleccione los que desee filtrar, esto se hace desde VB
> > > >
> > > > El problema es como hago un procedimiento almacenado para
> > > > paserle
los
> > > > parametros segun los campos que seleccione o necesariamente
> > > > debo
crear
> > > > parametro por campo ?
> > > >
> > > > SELECT IdVehiculo, Numero, IdClase, IdMarca, IdLinea,
> > > > IdColor,
> > > IdTipoVeh,
> > > > IdTipoMot, AnnoModelo, FecRepotencia, Ejes, NumLlantas,
> > > > PesoVeh,
> > > Pasajeros,
> > > > PasajPie, CapTanque, NumeroMotor,

SerieChasis,

> > > > Cilindrada, IdTipoCom, IdTipoLla, IdTipoLub, IdMarLla,
> > > > IdMarLub,
> > > IdEmpresa,
> > > > IdPropietario,
> > > > IdConductor, IdTipoPro,
> > > Adquisicion,IdGrupo,VehPropio,
> > > > IdProveedor, FecCompra, TarjetaProp, CostoCompra,
> > > > ValorAvaludo,
> > > > ValorAsegurado,ValorCupo, IdAdmon,
> > > > NumContrato,ContratoActivo,FecIngreso,
> > > > FecRetiro,FecVigencia,FecSalida, VidaUtil, FecImpuestos,
DocCompleta,
> > > > Accidentes,ObligaTProd,
> > > > PolizaSoat,FecSoat,VigSoat,EmpresaSoat
> > > >
> > ,GarantiaAcc,PolizaResCivil,FecResCivil,VigResCivil,
> > > > CertMovilizacion, FecCertMovil, VigCertMovil,
> > > > TarjetaOperacion,
> > > FecTarjOper,
> > > > VigTarjOper, CertGases, FecCertGases, VigCertGases,
> > > > Kilometraje, KmsCompra,
> > > > Observacion,CentInicial,CentFinal,CupoCredito,SaldoActual,
> ArchivoFoto,
> > > > IdEstado, FechaAdd, FechaUpdate, IdUsuario
> > > > FROM Vehiculos
> > > > WHERE ' aqui la condición que depende de los campos que

seleccione

> el
> > > > usuario
> > > >
> > > > gracias
> > > >
> > > >
> > > >
> > > > Diego
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>