Consultas duplicadas

Cuando he visto esto es porque se hace un "discover" de los parámetros es
decir se llama a un metodo del command que infiere los parámetros, y esto
provoca la instrucción con ese SET.

Es una mala práctica para el rendimiento y si de mí dependiera quitaría esa
funcionalidad del objeto command, es como si para llamar a una función de
..NET que has hecho tu usaras reflection para ver cuales son los parámetros,
en fin...


Miguel Egea Gómez

SQLServer MVP

Director de Servicios Corporativos

Solid Quality Learning Iberoamericana



"Solid Quality Learning es el proveedor global en el que puede confiar para
obtener soluciones y educación avanzada para la plataforma completa de
sistemas de bases de datos de Microsoft."

www.SolidQualityLearning.com


"Alejandro Mesa" escribió en el
mensaje news:
> Pablo,
>
>> Las sp las invoco desde una aplicación VB6 utilizando ADO 2.8
>
> Correcto, pero como lo haces?
>
> - usando el objeto "command" y llenando explicitamnete la coleccion de
> parametros
> - usando el objeto "connection"
> - ???
>
>
> AMB
>
>
> "Pablo Garateguy" wrote:
>
>> Las sp las invoco desde una aplicación VB6 utilizando ADO 2.8
>> Pablo Garateguy
>> MCP - Visual Basic 6
>>
>>
>> "Alejandro Mesa" wrote:
>>
>> > Pablo,
>> >
>> > Desde donde invocas el sp y como lo haces?
>> >
>> >
>> > AMB
>> >
>> > "Pablo Garateguy" wrote:
>> >
>> > > Estimados Foreros:
>> > >
>> > > Haciendo una revisión de unos traces, detectamos que
>> > > aparentemente
>> > > está ejecutando cada invocación a las sp en 2 ocasiones:
>> > >
>> > > SET FMTONLY ON Exec nombre_store_procedure @parametros SET FMTONLY
>> > > OFF
>> > > go
>> > > SET NO_BROWSETABLE OFF
>> > > go
>> > > Exec nombre_store_procedure @parametros
>> > > go
>> > >
>> > > Revisando la códificación es seguro que nosotros no lo estamos
>> > > invocando 2
>> > > veces, lo más extraño es que el comando SET FMTONLY ON (por lo que
>> > > estuve
>> > > leyendo), lo que hace es no permitir la devolución de datos, con lo
>> > > cual si
>> > > la sp devuelve datos, esta primera invocación no sirve para nada.
>> > >
>> > > El servidor es un W2003 y estamos con SQL Server 2000 Enterprise
>> > > Edition (SP
>> > > 4). El trace fue generado con los filtros por defecto.
>> > >
>> > > ¿Alguna idea de que puede estar pasando?
>> > >
>> > > Saludos
>> > > Pablo Garateguy
>> > > MCP - Visual Basic 6

Miguel,

Creo que te refieres al metodo "refresh" de la coleccion "parameters". Yo no
estoy seguro de que sea eso, pues en realidad este metodo lo que hace es
ejecutar un procedimiento para traer la info de los parametros (creo que
ejecuta sp_procedure_params_rowset).

Me pregunto si el sp esta llamando al sp usando la sintaxis ODBC (usando
placeholders ?) y .CommandType = adCmdText?

Seria bueno que Pablo posteara una muestra del codigo.


AMB


"Miguel Egea" wrote:

> Cuando he visto esto es porque se hace un "discover" de los parámetros es
> decir se llama a un metodo del command que infiere los parámetros, y esto
> provoca la instrucción con ese SET.
>
> Es una mala práctica para el rendimiento y si de mí dependiera quitaría esa
> funcionalidad del objeto command, es como si para llamar a una función de
> ..NET que has hecho tu usaras reflection para ver cuales son los parámetros,
> en fin...
>
>
> Miguel Egea Gómez
>
> SQLServer MVP
>
> Director de Servicios Corporativos
>
> Solid Quality Learning Iberoamericana
>
>
>
> "Solid Quality Learning es el proveedor global en el que puede confiar para
> obtener soluciones y educación avanzada para la plataforma completa de
> sistemas de bases de datos de Microsoft."
>
> www.SolidQualityLearning.com
>
>
> "Alejandro Mesa" escribió en el
> mensaje news:
> > Pablo,
> >
> >> Las sp las invoco desde una aplicación VB6 utilizando ADO 2.8
> >
> > Correcto, pero como lo haces?
> >
> > - usando el objeto "command" y llenando explicitamnete la coleccion de
> > parametros
> > - usando el objeto "connection"
> > - ???
> >
> >
> > AMB
> >
> >
> > "Pablo Garateguy" wrote:
> >
> >> Las sp las invoco desde una aplicación VB6 utilizando ADO 2.8
> >> Pablo Garateguy
> >> MCP - Visual Basic 6
> >>
> >>
> >> "Alejandro Mesa" wrote:
> >>
> >> > Pablo,
> >> >
> >> > Desde donde invocas el sp y como lo haces?
> >> >
> >> >
> >> > AMB
> >> >
> >> > "Pablo Garateguy" wrote:
> >> >
> >> > > Estimados Foreros:
> >> > >
> >> > > Haciendo una revisión de unos traces, detectamos que
> >> > > aparentemente
> >> > > está ejecutando cada invocación a las sp en 2 ocasiones:
> >> > >
> >> > > SET FMTONLY ON Exec nombre_store_procedure @parametros SET FMTONLY
> >> > > OFF
> >> > > go
> >> > > SET NO_BROWSETABLE OFF
> >> > > go
> >> > > Exec nombre_store_procedure @parametros
> >> > > go
> >> > >
> >> > > Revisando la códificación es seguro que nosotros no lo estamos
> >> > > invocando 2
> >> > > veces, lo más extraño es que el comando SET FMTONLY ON (por lo que
> >> > > estuve
> >> > > leyendo), lo que hace es no permitir la devolución de datos, con lo
> >> > > cual si
> >> > > la sp devuelve datos, esta primera invocación no sirve para nada.
> >> > >
> >> > > El servidor es un W2003 y estamos con SQL Server 2000 Enterprise
> >> > > Edition (SP
> >> > > 4). El trace fue generado con los filtros por defecto.
> >> > >
> >> > > ¿Alguna idea de que puede estar pasando?
> >> > >
> >> > > Saludos
> >> > > Pablo Garateguy
> >> > > MCP - Visual Basic 6
>
>
>

Perdón, utiliza el objeto command
Pablo Garateguy
MCP - Visual Basic 6


"Alejandro Mesa" wrote:

> Pablo,
>
> > Las sp las invoco desde una aplicación VB6 utilizando ADO 2.8
>
> Correcto, pero como lo haces?
>
> - usando el objeto "command" y llenando explicitamnete la coleccion de
> parametros
> - usando el objeto "connection"
> - ???
>
>
> AMB
>
>
> "Pablo Garateguy" wrote:
>
> > Las sp las invoco desde una aplicación VB6 utilizando ADO 2.8
> > Pablo Garateguy
> > MCP - Visual Basic 6
> >
> >
> > "Alejandro Mesa" wrote:
> >
> > > Pablo,
> > >
> > > Desde donde invocas el sp y como lo haces?
> > >
> > >
> > > AMB
> > >
> > > "Pablo Garateguy" wrote:
> > >
> > > > Estimados Foreros:
> > > >
> > > > Haciendo una revisión de unos traces, detectamos que aparentemente
> > > > está ejecutando cada invocación a las sp en 2 ocasiones:
> > > >
> > > > SET FMTONLY ON Exec nombre_store_procedure @parametros SET FMTONLY OFF
> > > > go
> > > > SET NO_BROWSETABLE OFF
> > > > go
> > > > Exec nombre_store_procedure @parametros
> > > > go
> > > >
> > > > Revisando la códificación es seguro que nosotros no lo estamos invocando 2
> > > > veces, lo más extraño es que el comando SET FMTONLY ON (por lo que estuve
> > > > leyendo), lo que hace es no permitir la devolución de datos, con lo cual si
> > > > la sp devuelve datos, esta primera invocación no sirve para nada.
> > > >
> > > > El servidor es un W2003 y estamos con SQL Server 2000 Enterprise Edition (SP
> > > > 4). El trace fue generado con los filtros por defecto.
> > > >
> > > > ¿Alguna idea de que puede estar pasando?
> > > >
> > > > Saludos
> > > > Pablo Garateguy
> > > > MCP - Visual Basic 6

Estimados Foreros:

Haciendo una revisión de unos traces, detectamos que aparentemente
está ejecutando cada invocación a las sp en 2 ocasiones:

SET FMTONLY ON Exec nombre_store_procedure @parametros SET FMTONLY OFF
go
SET NO_BROWSETABLE OFF
go
Exec nombre_store_procedure @parametros
go

Revisando la códificación es seguro que nosotros no lo estamos invocando 2
veces, lo más extraño es que el comando SET FMTONLY ON (por lo que estuve
leyendo), lo que hace es no permitir la devolución de datos, con lo cual
si
la sp devuelve datos, esta primera invocación no sirve para nada.

El servidor es un W2003 y estamos con SQL Server 2000 Enterprise Edition
(SP
4). El trace fue generado con los filtros por defecto.

¿Alguna idea de que puede estar pasando?

Saludos
Pablo Garateguy
MCP - Visual Basic 6

Miguel,

Quizas es este el sp que se ejecuta cuando usamos el metodo "refresh" de
la
colleccion "parameters" (sp_sproc_columns).


Saludos,

AMB

"Alejandro Mesa" wrote:

Miguel,

Creo que te refieres al metodo "refresh" de la coleccion "parameters". Yo
no
estoy seguro de que sea eso, pues en realidad este metodo lo que hace es
ejecutar un procedimiento para traer la info de los parametros (creo que
ejecuta sp_procedure_params_rowset).

Me pregunto si el sp esta llamando al sp usando la sintaxis ODBC (usando
placeholders ?) y .CommandType = adCmdText?

Seria bueno que Pablo posteara una muestra del codigo.


AMB


"Miguel Egea" wrote:

> Cuando he visto esto es porque se hace un "discover" de los parámetros
> es
> decir se llama a un metodo del command que infiere los parámetros, y
> esto
> provoca la instrucción con ese SET.
>
> Es una mala práctica para el rendimiento y si de mí dependiera quitaría
> esa
> funcionalidad del objeto command, es como si para llamar a una función
> de
> ..NET que has hecho tu usaras reflection para ver cuales son los
> parámetros,
> en fin...
>
>
> Miguel Egea Gómez
>
> SQLServer MVP
>
> Director de Servicios Corporativos
>
> Solid Quality Learning Iberoamericana
>
>
>
> "Solid Quality Learning es el proveedor global en el que puede confiar
> para
> obtener soluciones y educación avanzada para la plataforma completa de
> sistemas de bases de datos de Microsoft."
>
> www.SolidQualityLearning.com
>
>
> "Alejandro Mesa" escribió en
> el
> mensaje news:
> > Pablo,
> >
> >> Las sp las invoco desde una aplicación VB6 utilizando ADO 2.8
> >
> > Correcto, pero como lo haces?
> >
> > - usando el objeto "command" y llenando explicitamnete la coleccion
> > de
> > parametros
> > - usando el objeto "connection"
> > - ???
> >
> >
> > AMB
> >
> >
> > "Pablo Garateguy" wrote:
> >
> >> Las sp las invoco desde una aplicación VB6 utilizando ADO 2.8
> >> Pablo Garateguy
> >> MCP - Visual Basic 6
> >>
> >>
> >> "Alejandro Mesa" wrote:
> >>
> >> > Pablo,
> >> >
> >> > Desde donde invocas el sp y como lo haces?
> >> >
> >> >
> >> > AMB
> >> >
> >> > "Pablo Garateguy" wrote:
> >> >
> >> > > Estimados Foreros:
> >> > >
> >> > > Haciendo una revisión de unos traces, detectamos que
> >> > > aparentemente
> >> > > está ejecutando cada invocación a las sp en 2 ocasiones:
> >> > >
> >> > > SET FMTONLY ON Exec nombre_store_procedure @parametros SET
> >> > > FMTONLY
> >> > > OFF
> >> > > go
> >> > > SET NO_BROWSETABLE OFF
> >> > > go
> >> > > Exec nombre_store_procedure @parametros
> >> > > go
> >> > >
> >> > > Revisando la códificación es seguro que nosotros no lo estamos
> >> > > invocando 2
> >> > > veces, lo más extraño es que el comando SET FMTONLY ON (por lo
> >> > > que
> >> > > estuve
> >> > > leyendo), lo que hace es no permitir la devolución de datos, con
> >> > > lo
> >> > > cual si
> >> > > la sp devuelve datos, esta primera invocación no sirve para
> >> > > nada.
> >> > >
> >> > > El servidor es un W2003 y estamos con SQL Server 2000 Enterprise
> >> > > Edition (SP
> >> > > 4). El trace fue generado con los filtros por defecto.
> >> > >
> >> > > ¿Alguna idea de que puede estar pasando?
> >> > >
> >> > > Saludos
> >> > > Pablo Garateguy
> >> > > MCP - Visual Basic 6
>
>
>