Procedimientos Almacenados - Parametros

Cuestión de opiniones.

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

Tener "Todo" (0%) previsto (inclusive todas las posibles consultas
requeridas) para una aplicación es prácticamente imposible para mí. A menos
que te tomes años en desarrollarla o sea un producto de paquete estático y
depurado por años. Si este es el caso a que te refieres pues tienes toda la
razón. Para mí sería deseable trabajar así pero no puedo (sería
antieconómico) tardar en exceso para liberar una aplicación (trabajo para
muchos clientes y con productos no empaquetados).

Además lo de la optimización tampoco puede ser 100% pues las estadísticas se
van generando en producción.

indices creados en las tablas, ya sean clustered o no.

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?

Claro que no, pero se les otorgan derechos de "lectura" a las tablas que
usará la consulta ad-hoc en cuestión (que es de lo que estamos hablando para
que no se pierda de vista). No a todas las tablas si el usuario no lo
requiere. Las tablas que necesitarán siempre estarán "previstas". Para las
demás consultas normales y típicas de la aplicación (que son la gran
mayoría) yo hago igual que tú: tengo un SP bien depurado.

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.

Vuelvo a lo mismo. Depende de la frecuencia de uso de la consulta (hablo
desde la aplicación cliente). Si es una "pantalla" de uso frecuente en la
aplicacion y un usuario suele hacer busquedas ad-hoc casi a diario (lo cual
es raro) pues de acuerdo. Así debería ser como dices.

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.

Depende de cómo programes tu aplicación. En el cliente tienes más libertad
para código genérico de manejo de datos (en la capa de datos) que no dependa
de nombres de identificadores. Cuando digo "genérico" no me refiero a
"sql's dinamicos en SQL server" pues ustedes siempre interpretan eso, sino
a una librería de clases independiente de los nombres de identificadores de
la BD. Las reglas de negocio ya son otra cosa.

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

datos.

Claro que sí. Pero una consultica ad-hoc de uso eventual no le hace daño a
nadie.


Saludos y Feliz año

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

el sql injection se produce por el armado de sql dinamicamente, ya sea
en el sp o en tu programa.

Como se puede producir la injection de codigo sql en el programa del cliente
? No seria en un sp de la BD ?


Este es un buen link sobre ese tema.
http://www.hayes.ch/sql/sql_dinamico.html


Melissa Ruiz

Oye una pregunta al ver estos temas:


Cuando uno en un sistema tiene un dataset y ordena al dataset que inserte un
registro mandando a ejecutar el metodo digamos "INSERTRECORD", que es lo que
hace realmente el dataset ? no es enviar una simple instruccion INSERT al
servidor ? Aqui no existe ningun SP que yo sepa , a no ser que una misma
lo haya creado.
Si fuera tan necesario un SP hasta para esto, los lenguajes de programacion
que manejan bases de datos los exigirian. o no ?


La verdad que estoy confundida y mi opinión es que exageran un poco con eso
de usar un SP para todo.


Melissa Ruiz





"MAXI" wrote in message
news:

Ricardo, creo que te estas basando en que un sp's es solo bueno por
performance, si miras ese lado solo, algunas de las cosas que decis son
ciertas :-)

El tema es que no estas haciendo un analisis completo del tema, por ej: no
mencionas que si no usas un Sp's vas a tener que darle acceso directo a

los

usuarios a tus tablas, no mencionas nada de mantenimiento por ej, a ver:

que

pasa si cambia algo en la BDD? debemos ir a buscar en toda aplicacion

donde

este y volver a compilarlo, cuando si realmente usaras Sp's seria una

tarea

muy simple.

Tampoco hablas de abstraccion, cuando trabajas en equipos de trabajos los
desarrolladores por lo general se encargan del codigo de la aplicacion y
nada de la BDD, por lo cual para ellos los Sp's son la forma de conectar

un

mundo con el otro sin importar que suceda atras :-)

Yo no soy un sp's maniaco, solo considero que son la herramienta que
soluciona muchos de los problemas mas importantes de una aplicacion y que
sin ellos no los podrias resolver. Ahora, quizas para ti no sea

prioritario

la seguridad - la performance, con lo cual mandar sentencias desde el
cliente parece lo mas acertado, pues eso va en cada uno, es como todo, los
software tambien tienen calidad como los autos, un BMW es un auto y un

FIAT

tambien, pero sabemos que no son lo mismo.

Ademas hacer las cosas bien no cuesta nada, es probable que por las
aplicaciones que hagas no se vea la diferencia, pero al estar acostumbrado

a

las buenas practicas de programacion, cuando debas hacer un sistema para

un

cliente mas exigente no tendras problemas.

Un abrazo y Feliz 2005




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)

Msn Messenger:

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

Porqué es que siempre todo para ustedes tiene que ser blanco o negro ? Yo
no he dicho que no uso SP's , los uso mucho hasta para los cruds, y para la
mayoria de consultas "previstas". Aqui estamos hablando de una consulta
ad-hoc. Si leen bien mi mensaje ahí lo digo.

El tema es que no estas haciendo un analisis completo del tema, por ej: no
mencionas que si no usas un Sp's vas a tener que darle acceso directo a

los

usuarios a tus tablas,

bueno... acceso de consulta para tablas especificas. Cual es el problema ?

no mencionas nada de mantenimiento por ej, a ver: que
pasa si cambia algo en la BDD? debemos ir a buscar en toda aplicacion

donde

este y volver a compilarlo, cuando si realmente usaras Sp's seria una

tarea

muy simple.

Y tú programas tu aplicación, tus clases de manejo de datos (de capa de
datos) con código "duro" dependiente de la base de datos ? bueno... si es
así, tienes razón en lo que dices pero usas muy malas prácticas de
programación. En mi caso yo una consulta ad-hoc (que es una clase
parametrizable) la programo de forma genérica en la aplicación.

Tampoco hablas de abstraccion, cuando trabajas en equipos de trabajos los
desarrolladores por lo general se encargan del codigo de la aplicacion y
nada de la BDD, por lo cual para ellos los Sp's son la forma de conectar

un

mundo con el otro sin importar que suceda atras :-)

Perfecto. Para darte solo un ejemplo ej. yo tengo para cada tabla un sp
XSP_I_NOMBRETABLA con los campos en parametros para insertar un registro.
Mis clases en la capa de datos de la aplicacion construyen (build) con el
nombre de la tabla y su estructura la cadena de llamada al SP y la lista de
parametros a pasar a este SP. Los desarrolladores solo saben que hay una
rutina para cada tabla que espera un registro y un nombre de tabla. La
clase se encarga del resto. No hay ningún código "duro" aquí. Tambien
tengo SP's para consultas con nombres predeterminados coincidiendo con
nombres de forms para simplificar y generalizar el asunto, aqui tampoco hay
nada de codigo duro. Lo que quiero decir que si tu programas tus clases de
capa de datos en la aplicación a un nivel de abstracción (evitando la
cohesión), los problemas de mantenimiento son mínimos.

Yo no soy un sp's maniaco, solo considero que son la herramienta que
soluciona muchos de los problemas mas importantes de una aplicacion y que
sin ellos no los podrias resolver. Ahora, quizas para ti no sea

prioritario

la seguridad - la performance, con lo cual mandar sentencias desde el
cliente parece lo mas acertado,

Insisto, no es para todos los casos. No generalices. Relee mi mensaje.

pues eso va en cada uno, es como todo, los
software tambien tienen calidad como los autos, un BMW es un auto y un

FIAT

tambien, pero sabemos que no son lo mismo.

Ademas hacer las cosas bien no cuesta nada, es probable que por las
aplicaciones que hagas no se vea la diferencia, pero al estar acostumbrado

a

las buenas practicas de programacion, cuando debas hacer un sistema para

un

cliente mas exigente no tendras problemas.

Una aplicación no es sólo el servidor (el manejador de la base de datos). La
aplicación cliente es también muy importante y parte esencial del "todo"
C/S.

Para concluir: A mi me luces que sólo te centras en el área del servidor y
piensas que la programación en la parte cliente es tan rígida como lo es (o
debe ser) en la parte servidor el T-SQL para que el servidor se maneje
eficientemente y con seguridad. En la aplicacion cliente uno tiene mayor
libertad de hacer cosas de modo genérico aunque se utilicen los SP's como
base fundamental del acceso a datos, son capas diferentes e independientes.
Todo depende de cómo programes tu aplicación y del dominio que tengas del
lenguaje de programación y del conocimiento que tengas del desarrollo en
N-Capas.

Un abrazo y Feliz 2005

Igual. Muchas felicidades.

Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)

Msn Messenger:

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