conexion a BD

20/04/2006 - 13:48 por Piolin Net | Informe spam
Alo!

Tengo una duda existencial ...

¿Que es mejor, abrir un recordset con el objeto conexion o hacerlo con el
objeto command intermedio?

osea,
1.- con el objeto conexion:

rs.open "sp_procedimiento_almacenado", objeto_conexion, adOpenStatic,
adLockOptimistic

2.- con el objeto commad:

With objeto_commad
.CommandText = "sp_procedimiento_almacenado"
.CommandType = adCmdStoredProc
.ActiveConnection = objeto_conexion
.Parameters.Refresh
End With

rs.Open objeto_commad, , adOpenStatic, adLockOptimistic

* En cuanto a velocidad, gestion de recursos y bla bla.

Gracias.

Preguntas similare

Leer las respuestas

#6 German Saer
21/04/2006 - 04:13 | Informe spam
Piolin,

Bajo HTTP, todos los recordsets trabajan deconectados and ASP clasico. Una
vez se cargan los datos en la pagina, el objeto recordset se desconecta,
aunque es recomendable siempre que tu los cierres tu a mano. Ambos metodos
son basicamente lo mismo.

Thanks,

_______________
German Saer
Orlando, FL 32810




"Matías Iacono" wrote in message
news:
Si, me falto aclarar un par de cosas :)

En realidad, la clave de la primer opcion y esa esta en el .LockType > adLockReadOnly '1

Donde puedes darle bloqueo por registro, por tabla, o como en este coso,


que
sea de solo lectura.

Pero para poder explicarlo de mejor manera, podemos mirar un poco .Net.

Donde podemos ver un nuevo modelo de acceso a datos, como por ejemplo, un
DataSet vs. un DataReader.

Aunque no bloquees la tabla, porque lo haces de solo lectura, debes


mantener
una conexion activa (al igual que en un DataReader), a la base de datos,


lo
que puede consumirte recursos, o en un punto, hacer el acceso a la base de
datos más lenta, debido a que puede tener muchas conexiones en cola y


otros
asuntos.

Entonces, mientras haces todo el trabajo con la base de datos, la conexion


a
la DB sigue vigente, y si tienes muchos procesos, ademas le sumas muchos
usuarios, terminas haciendo mas lenta tu aplicacion.

Con el segundo caso, al igual que un DataSet, nos conectamos a la DB,
consultamos los datos, y en ese mismo momento podemos cerrar la conexion,
con la diferencia que todos los datos los tenemos a mano.

Saludos.

Matías Iacono
Microsoft MVP ASP/ASP.net
Microsoft Student Ambassador
Coordinador de evento Comunidad MSDN Bolivia
DCE2 v.2005
"Manuel Vera" escribió en el mensaje
news:
>Y la diferencia entre el Command del amigo y esta otra opciòn:
>
> 3.-
> with gData
> .CursorLocation = adUseClient
> .CursorType = adOpenForwardOnly '0
> .LockType = adLockReadOnly '1
> .Open SQL, gConnect
> set .ActiveConnection = nothing
> end with
>
> Salu2
> MV
>
>
> "Matías Iacono" escribió en el mensaje
> news:
>> En teoría si :p
>>
>> Matías Iacono
>> Microsoft MVP ASP/ASP.net
>> Microsoft Student Ambassador
>> Coordinador de evento Comunidad MSDN Bolivia
>> DCE2 v.2005
>> "Piolin Net" escribió en el


mensaje
>> news:
>>>
>>> Osea,
>>>
>>> ¿con la opcion 1 la tabla se queda bloqueada hasta que cierras el
>>> recordset?
>>>
>>> Gracias.
>>>
>>> "Matías Iacono" escribió:
>>>
>>>> Personalmente prefiero la segnda opcion.
>>>>
>>>> Ya que se podría decir que es una forma de trabjo desconectado.
>>>>
>>>> O sea, abres la base de datos, ejecutas la consulta y retornas un set
>>>> de
>>>> datos.
>>>>
>>>> Esto hace que la tabla no quede bloqueada, y puedas trabajar con el
>>>> recordset sin estar conectado directamente a la base de datos.
>>>>
>>>> Matías Iacono
>>>> Microsoft MVP ASP/ASP.net
>>>> Microsoft Student Ambassador
>>>> Coordinador de evento Comunidad MSDN Bolivia
>>>> DCE2 v.2005
>>>> "Piolin Net" escribió en el
>>>> mensaje
>>>> news:
>>>> > Alo!
>>>> >
>>>> > Tengo una duda existencial ...
>>>> >
>>>> > ¿Que es mejor, abrir un recordset con el objeto conexion o hacerlo
>>>> > con el
>>>> > objeto command intermedio?
>>>> >
>>>> > osea,
>>>> > 1.- con el objeto conexion:
>>>> >
>>>> > rs.open "sp_procedimiento_almacenado", objeto_conexion,


adOpenStatic,
>>>> > adLockOptimistic
>>>> >
>>>> > 2.- con el objeto commad:
>>>> >
>>>> > With objeto_commad
>>>> > .CommandText = "sp_procedimiento_almacenado"
>>>> > .CommandType = adCmdStoredProc
>>>> > .ActiveConnection = objeto_conexion
>>>> > .Parameters.Refresh
>>>> > End With
>>>> >
>>>> > rs.Open objeto_commad, , adOpenStatic, adLockOptimistic
>>>> >
>>>> > * En cuanto a velocidad, gestion de recursos y bla bla.
>>>> >
>>>> > Gracias.
>>>>
>>>>
>>>>
>>
>>
>
>


Respuesta Responder a este mensaje
#7 Piolin Net
21/04/2006 - 13:06 | Informe spam
Gracias a todos,

La verdad es que me he quedado igual, sin saber cual de las 2 opciones es
mas recomendable. Me pillaré algun manual de ADO por ahi.

Zenks a lot

"German Saer" escribió:

Piolin,

Bajo HTTP, todos los recordsets trabajan deconectados and ASP clasico. Una
vez se cargan los datos en la pagina, el objeto recordset se desconecta,
aunque es recomendable siempre que tu los cierres tu a mano. Ambos metodos
son basicamente lo mismo.

Thanks,

_______________
German Saer
Orlando, FL 32810




"Matías Iacono" wrote in message
news:
> Si, me falto aclarar un par de cosas :)
>
> En realidad, la clave de la primer opcion y esa esta en el .LockType > > adLockReadOnly '1
>
> Donde puedes darle bloqueo por registro, por tabla, o como en este coso,
que
> sea de solo lectura.
>
> Pero para poder explicarlo de mejor manera, podemos mirar un poco .Net.
>
> Donde podemos ver un nuevo modelo de acceso a datos, como por ejemplo, un
> DataSet vs. un DataReader.
>
> Aunque no bloquees la tabla, porque lo haces de solo lectura, debes
mantener
> una conexion activa (al igual que en un DataReader), a la base de datos,
lo
> que puede consumirte recursos, o en un punto, hacer el acceso a la base de
> datos más lenta, debido a que puede tener muchas conexiones en cola y
otros
> asuntos.
>
> Entonces, mientras haces todo el trabajo con la base de datos, la conexion
a
> la DB sigue vigente, y si tienes muchos procesos, ademas le sumas muchos
> usuarios, terminas haciendo mas lenta tu aplicacion.
>
> Con el segundo caso, al igual que un DataSet, nos conectamos a la DB,
> consultamos los datos, y en ese mismo momento podemos cerrar la conexion,
> con la diferencia que todos los datos los tenemos a mano.
>
> Saludos.
>
> Matías Iacono
> Microsoft MVP ASP/ASP.net
> Microsoft Student Ambassador
> Coordinador de evento Comunidad MSDN Bolivia
> DCE2 v.2005
> "Manuel Vera" escribió en el mensaje
> news:
> >Y la diferencia entre el Command del amigo y esta otra opciòn:
> >
> > 3.-
> > with gData
> > .CursorLocation = adUseClient
> > .CursorType = adOpenForwardOnly '0
> > .LockType = adLockReadOnly '1
> > .Open SQL, gConnect
> > set .ActiveConnection = nothing
> > end with
> >
> > Salu2
> > MV
> >
> >
> > "Matías Iacono" escribió en el mensaje
> > news:
> >> En teoría si :p
> >>
> >> Matías Iacono
> >> Microsoft MVP ASP/ASP.net
> >> Microsoft Student Ambassador
> >> Coordinador de evento Comunidad MSDN Bolivia
> >> DCE2 v.2005
> >> "Piolin Net" escribió en el
mensaje
> >> news:
> >>>
> >>> Osea,
> >>>
> >>> ¿con la opcion 1 la tabla se queda bloqueada hasta que cierras el
> >>> recordset?
> >>>
> >>> Gracias.
> >>>
> >>> "Matías Iacono" escribió:
> >>>
> >>>> Personalmente prefiero la segnda opcion.
> >>>>
> >>>> Ya que se podría decir que es una forma de trabjo desconectado.
> >>>>
> >>>> O sea, abres la base de datos, ejecutas la consulta y retornas un set
> >>>> de
> >>>> datos.
> >>>>
> >>>> Esto hace que la tabla no quede bloqueada, y puedas trabajar con el
> >>>> recordset sin estar conectado directamente a la base de datos.
> >>>>
> >>>> Matías Iacono
> >>>> Microsoft MVP ASP/ASP.net
> >>>> Microsoft Student Ambassador
> >>>> Coordinador de evento Comunidad MSDN Bolivia
> >>>> DCE2 v.2005
> >>>> "Piolin Net" escribió en el
> >>>> mensaje
> >>>> news:
> >>>> > Alo!
> >>>> >
> >>>> > Tengo una duda existencial ...
> >>>> >
> >>>> > ¿Que es mejor, abrir un recordset con el objeto conexion o hacerlo
> >>>> > con el
> >>>> > objeto command intermedio?
> >>>> >
> >>>> > osea,
> >>>> > 1.- con el objeto conexion:
> >>>> >
> >>>> > rs.open "sp_procedimiento_almacenado", objeto_conexion,
adOpenStatic,
> >>>> > adLockOptimistic
> >>>> >
> >>>> > 2.- con el objeto commad:
> >>>> >
> >>>> > With objeto_commad
> >>>> > .CommandText = "sp_procedimiento_almacenado"
> >>>> > .CommandType = adCmdStoredProc
> >>>> > .ActiveConnection = objeto_conexion
> >>>> > .Parameters.Refresh
> >>>> > End With
> >>>> >
> >>>> > rs.Open objeto_commad, , adOpenStatic, adLockOptimistic
> >>>> >
> >>>> > * En cuanto a velocidad, gestion de recursos y bla bla.
> >>>> >
> >>>> > Gracias.
> >>>>
> >>>>
> >>>>
> >>
> >>
> >
> >
>
>



Respuesta Responder a este mensaje
#8 Matías Iacono
21/04/2006 - 17:15 | Informe spam
Tienes razón de lo que dices, pero esto se produce cuando la página ya se
terminó de cargar y envió todo su contenido al navegador.

El problema esta en el "mientras tanto". Si tienes, por ejemplo, gran
cantidad de lógica con conexion a una base de datos, en el transcurso de
este codigo, mantendrás la coneccion activa, y ahí te pueden pasar todos los
problemas que se trataron con anterioridad.

Espero entiendas la diferencia.

Saludos.

Matías Iacono
Microsoft MVP ASP/ASP.net
Microsoft Student Ambassador
Coordinador de evento Comunidad MSDN Bolivia
DCE2 v.2005
"German Saer" escribió en el mensaje
news:ScX1g.51$
Piolin,

Bajo HTTP, todos los recordsets trabajan deconectados and ASP clasico.
Una
vez se cargan los datos en la pagina, el objeto recordset se desconecta,
aunque es recomendable siempre que tu los cierres tu a mano. Ambos
metodos
son basicamente lo mismo.

Thanks,

_______________
German Saer
Orlando, FL 32810




"Matías Iacono" wrote in message
news:
Si, me falto aclarar un par de cosas :)

En realidad, la clave de la primer opcion y esa esta en el .LockType >> adLockReadOnly '1

Donde puedes darle bloqueo por registro, por tabla, o como en este coso,


que
sea de solo lectura.

Pero para poder explicarlo de mejor manera, podemos mirar un poco .Net.

Donde podemos ver un nuevo modelo de acceso a datos, como por ejemplo, un
DataSet vs. un DataReader.

Aunque no bloquees la tabla, porque lo haces de solo lectura, debes


mantener
una conexion activa (al igual que en un DataReader), a la base de datos,


lo
que puede consumirte recursos, o en un punto, hacer el acceso a la base
de
datos más lenta, debido a que puede tener muchas conexiones en cola y


otros
asuntos.

Entonces, mientras haces todo el trabajo con la base de datos, la
conexion


a
la DB sigue vigente, y si tienes muchos procesos, ademas le sumas muchos
usuarios, terminas haciendo mas lenta tu aplicacion.

Con el segundo caso, al igual que un DataSet, nos conectamos a la DB,
consultamos los datos, y en ese mismo momento podemos cerrar la conexion,
con la diferencia que todos los datos los tenemos a mano.

Saludos.

Matías Iacono
Microsoft MVP ASP/ASP.net
Microsoft Student Ambassador
Coordinador de evento Comunidad MSDN Bolivia
DCE2 v.2005
"Manuel Vera" escribió en el mensaje
news:
>Y la diferencia entre el Command del amigo y esta otra opciòn:
>
> 3.-
> with gData
> .CursorLocation = adUseClient
> .CursorType = adOpenForwardOnly '0
> .LockType = adLockReadOnly '1
> .Open SQL, gConnect
> set .ActiveConnection = nothing
> end with
>
> Salu2
> MV
>
>
> "Matías Iacono" escribió en el mensaje
> news:
>> En teoría si :p
>>
>> Matías Iacono
>> Microsoft MVP ASP/ASP.net
>> Microsoft Student Ambassador
>> Coordinador de evento Comunidad MSDN Bolivia
>> DCE2 v.2005
>> "Piolin Net" escribió en el


mensaje
>> news:
>>>
>>> Osea,
>>>
>>> ¿con la opcion 1 la tabla se queda bloqueada hasta que cierras el
>>> recordset?
>>>
>>> Gracias.
>>>
>>> "Matías Iacono" escribió:
>>>
>>>> Personalmente prefiero la segnda opcion.
>>>>
>>>> Ya que se podría decir que es una forma de trabjo desconectado.
>>>>
>>>> O sea, abres la base de datos, ejecutas la consulta y retornas un
>>>> set
>>>> de
>>>> datos.
>>>>
>>>> Esto hace que la tabla no quede bloqueada, y puedas trabajar con el
>>>> recordset sin estar conectado directamente a la base de datos.
>>>>
>>>> Matías Iacono
>>>> Microsoft MVP ASP/ASP.net
>>>> Microsoft Student Ambassador
>>>> Coordinador de evento Comunidad MSDN Bolivia
>>>> DCE2 v.2005
>>>> "Piolin Net" escribió en el
>>>> mensaje
>>>> news:
>>>> > Alo!
>>>> >
>>>> > Tengo una duda existencial ...
>>>> >
>>>> > ¿Que es mejor, abrir un recordset con el objeto conexion o hacerlo
>>>> > con el
>>>> > objeto command intermedio?
>>>> >
>>>> > osea,
>>>> > 1.- con el objeto conexion:
>>>> >
>>>> > rs.open "sp_procedimiento_almacenado", objeto_conexion,


adOpenStatic,
>>>> > adLockOptimistic
>>>> >
>>>> > 2.- con el objeto commad:
>>>> >
>>>> > With objeto_commad
>>>> > .CommandText = "sp_procedimiento_almacenado"
>>>> > .CommandType = adCmdStoredProc
>>>> > .ActiveConnection = objeto_conexion
>>>> > .Parameters.Refresh
>>>> > End With
>>>> >
>>>> > rs.Open objeto_commad, , adOpenStatic, adLockOptimistic
>>>> >
>>>> > * En cuanto a velocidad, gestion de recursos y bla bla.
>>>> >
>>>> > Gracias.
>>>>
>>>>
>>>>
>>
>>
>
>






Respuesta Responder a este mensaje
#9 Matías Iacono
21/04/2006 - 17:16 | Informe spam
Bueno, si quieres mi opinion personal, la mejor opcion es la segunda, o sea,
la desconectada.

Aunque posiblemente tendrías más intentos de conexion y desconexion a la DB,
finalmente obtendrías mejor rendimiento al tener un recordset desconectado
(Si manejas grandes volumenes de datos en tus consultas)

saludos.

Matías Iacono
Microsoft MVP ASP/ASP.net
Microsoft Student Ambassador
Coordinador de evento Comunidad MSDN Bolivia
DCE2 v.2005
"Piolin Net" escribió en el mensaje
news:
Gracias a todos,

La verdad es que me he quedado igual, sin saber cual de las 2 opciones es
mas recomendable. Me pillaré algun manual de ADO por ahi.

Zenks a lot

"German Saer" escribió:

Piolin,

Bajo HTTP, todos los recordsets trabajan deconectados and ASP clasico.
Una
vez se cargan los datos en la pagina, el objeto recordset se desconecta,
aunque es recomendable siempre que tu los cierres tu a mano. Ambos
metodos
son basicamente lo mismo.

Thanks,

_______________
German Saer
Orlando, FL 32810




"Matías Iacono" wrote in message
news:
> Si, me falto aclarar un par de cosas :)
>
> En realidad, la clave de la primer opcion y esa esta en el .LockType >> > adLockReadOnly '1
>
> Donde puedes darle bloqueo por registro, por tabla, o como en este
> coso,
que
> sea de solo lectura.
>
> Pero para poder explicarlo de mejor manera, podemos mirar un poco .Net.
>
> Donde podemos ver un nuevo modelo de acceso a datos, como por ejemplo,
> un
> DataSet vs. un DataReader.
>
> Aunque no bloquees la tabla, porque lo haces de solo lectura, debes
mantener
> una conexion activa (al igual que en un DataReader), a la base de
> datos,
lo
> que puede consumirte recursos, o en un punto, hacer el acceso a la base
> de
> datos más lenta, debido a que puede tener muchas conexiones en cola y
otros
> asuntos.
>
> Entonces, mientras haces todo el trabajo con la base de datos, la
> conexion
a
> la DB sigue vigente, y si tienes muchos procesos, ademas le sumas
> muchos
> usuarios, terminas haciendo mas lenta tu aplicacion.
>
> Con el segundo caso, al igual que un DataSet, nos conectamos a la DB,
> consultamos los datos, y en ese mismo momento podemos cerrar la
> conexion,
> con la diferencia que todos los datos los tenemos a mano.
>
> Saludos.
>
> Matías Iacono
> Microsoft MVP ASP/ASP.net
> Microsoft Student Ambassador
> Coordinador de evento Comunidad MSDN Bolivia
> DCE2 v.2005
> "Manuel Vera" escribió en el mensaje
> news:
> >Y la diferencia entre el Command del amigo y esta otra opciòn:
> >
> > 3.-
> > with gData
> > .CursorLocation = adUseClient
> > .CursorType = adOpenForwardOnly '0
> > .LockType = adLockReadOnly '1
> > .Open SQL, gConnect
> > set .ActiveConnection = nothing
> > end with
> >
> > Salu2
> > MV
> >
> >
> > "Matías Iacono" escribió en el mensaje
> > news:
> >> En teoría si :p
> >>
> >> Matías Iacono
> >> Microsoft MVP ASP/ASP.net
> >> Microsoft Student Ambassador
> >> Coordinador de evento Comunidad MSDN Bolivia
> >> DCE2 v.2005
> >> "Piolin Net" escribió en el
mensaje
> >> news:
> >>>
> >>> Osea,
> >>>
> >>> ¿con la opcion 1 la tabla se queda bloqueada hasta que cierras el
> >>> recordset?
> >>>
> >>> Gracias.
> >>>
> >>> "Matías Iacono" escribió:
> >>>
> >>>> Personalmente prefiero la segnda opcion.
> >>>>
> >>>> Ya que se podría decir que es una forma de trabjo desconectado.
> >>>>
> >>>> O sea, abres la base de datos, ejecutas la consulta y retornas un
> >>>> set
> >>>> de
> >>>> datos.
> >>>>
> >>>> Esto hace que la tabla no quede bloqueada, y puedas trabajar con
> >>>> el
> >>>> recordset sin estar conectado directamente a la base de datos.
> >>>>
> >>>> Matías Iacono
> >>>> Microsoft MVP ASP/ASP.net
> >>>> Microsoft Student Ambassador
> >>>> Coordinador de evento Comunidad MSDN Bolivia
> >>>> DCE2 v.2005
> >>>> "Piolin Net" escribió en el
> >>>> mensaje
> >>>> news:
> >>>> > Alo!
> >>>> >
> >>>> > Tengo una duda existencial ...
> >>>> >
> >>>> > ¿Que es mejor, abrir un recordset con el objeto conexion o
> >>>> > hacerlo
> >>>> > con el
> >>>> > objeto command intermedio?
> >>>> >
> >>>> > osea,
> >>>> > 1.- con el objeto conexion:
> >>>> >
> >>>> > rs.open "sp_procedimiento_almacenado", objeto_conexion,
adOpenStatic,
> >>>> > adLockOptimistic
> >>>> >
> >>>> > 2.- con el objeto commad:
> >>>> >
> >>>> > With objeto_commad
> >>>> > .CommandText = "sp_procedimiento_almacenado"
> >>>> > .CommandType = adCmdStoredProc
> >>>> > .ActiveConnection = objeto_conexion
> >>>> > .Parameters.Refresh
> >>>> > End With
> >>>> >
> >>>> > rs.Open objeto_commad, , adOpenStatic, adLockOptimistic
> >>>> >
> >>>> > * En cuanto a velocidad, gestion de recursos y bla bla.
> >>>> >
> >>>> > Gracias.
> >>>>
> >>>>
> >>>>
> >>
> >>
> >
> >
>
>



email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una pregunta AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida