conexion ado net

Pero el hecho que tenga abierta permanentemente la conexion o no.. no le
quita lo desconectado.
"DosFlores" escribió en el mensaje
news:%
Mostrar la cita

En ADO que se utiliza en VB6 no es mala idea tenerlo abierto ya que
trabajas con recordsets conectados a tu bd, en ADO. NET eso cambia, la
idea es trabajar con datos desconectados de la bd, tienes un artículo del
Guille en el dotNetMania del mes de Abril donde empieza una serie para
ADO.NET que es bastante interesante, además tienes los Microsoft Patterns
& Practices donde también lo explican perfectamente, para .NET tienes lo
siguiente:
http://msdn.microsoft.com/practices...l/daag.asp

Un saludo
Oscar Montesinos
"Eduardo Alvarado Meza" <ealvarado_15@(eliminarestetexto)hotmail.com>
escribió en el mensaje news:
Mostrar la cita

Esto es bien interesante y hasta me lo han preguntado a mi tambien varios
compañeros, por lo general en el VB2005, con todos estos asistentes, cada
cosita tiene su propia conexion, por ejemplo los adaptadores del dataset
tipado.

Mi pregunta es se podria decir que la logica que emplean algunos
sistemas de abrir la conexion al principio de la ejecucion y cerrarla al
final de la aplicacion, manteniendola abierta todo la vida del programa
donde todas las operaciones fluyen unicamente por esa conexion no es tan
mala idea? Es decir, absolutamente todo fluye por una unica conexion.

Depende de la lógica de tu aplicación, en mi caso abro y cierro la conexion
bastantes veces, por lo que el uso del objeto sqlconnection es contínuo, así
que no lo destruyo hasta que se cierra la aplicación. También tengo en
cuenta que algunos de mis clientes trabajan en MSDE y no me interesa tener
muchas conexiones abiertas contra el servidor, por otro lado también intento
evitar que la concurrencia contra SQL no sea muy alta por el tema de las
licencias, tengo clientes con 10-15 puestos de los cuales solo habrá unos 5
trabajando simultáneamente contra el servidor.

Un saludo
Oscar Montesinos
"jboscaroli" escribió en el mensaje
news:
Mostrar la cita

la conexion se debe cerrar con close y mantener el objeto sqlconnection
creado o es lo mismo destruir el objeto sqlconnection y volver a crearlo
cuando se necesite??



"DosFlores" escribió en el mensaje
news:#
Mostrar la cita

En ADO que se utiliza en VB6 no es mala idea tenerlo abierto ya que

trabajas
Mostrar la cita

con recordsets conectados a tu bd, en ADO. NET eso cambia, la idea es
trabajar con datos desconectados de la bd, tienes un artículo del Guille

en
Mostrar la cita

el dotNetMania del mes de Abril donde empieza una serie para ADO.NET que

es
Mostrar la cita

bastante interesante, además tienes los Microsoft Patterns & Practices

donde
Mostrar la cita

también lo explican perfectamente, para .NET tienes lo siguiente:

http://msdn.microsoft.com/practices...rary/en-us
/dnbda/html/daag.asp
Mostrar la cita

Un saludo
Oscar Montesinos
"Eduardo Alvarado Meza" <ealvarado_15@(eliminarestetexto)hotmail.com>
escribió en el mensaje news:
> Esto es bien interesante y hasta me lo han preguntado a mi tambien

varios
Mostrar la cita

> compañeros, por lo general en el VB2005, con todos estos asistentes,

cada
Mostrar la cita

> cosita tiene su propia conexion, por ejemplo los adaptadores del
> dataset
> tipado.
>
> Mi pregunta es se podria decir que la logica que emplean algunos
> sistemas de abrir la conexion al principio de la ejecucion y cerrarla
> al
> final de la aplicacion, manteniendola abierta todo la vida del programa
> donde todas las operaciones fluyen unicamente por esa conexion no es
> tan
> mala idea? Es decir, absolutamente todo fluye por una unica conexion.
>