SQL Server cierra la conexión

03/07/2007 - 16:29 por Eclat | Informe spam

Muy buenas de nuevo, tengo un problemilla que después de mucho pelear
pensando que era un problema del W2003 R2, creo que va a venir más bien
por el SQL Server 2005.

Resulta que en la oficina tenemos instalado un ERP. Todos los usuarios
se conectan por Terminal Server a un servidor de aplicaciones, que a su
vez, cuando ejecutan el ERP, éste se conecta a una base de datos que hay
en un servidor de datos.

El caso es que cuando un usuario determinado deja el ordenador un rato
sin hacer nada (me refiero al ERP, es decir, no trabaja dentro de la
sesión de TS), la conexión con la BD se pierde, con lo que el programa
comienza a fallar como una escopeta de feria sin razón aparente. Además,
dependiendo del proceso que estuviese realizando pues puede ser más o
menos peligroso.

Mirando y mirando, he visto en el SQL Server Configuration Manager, en
Configuración de red de SQL Server 2005 que está habilitado Memoria
Compartida (que no sé si no será mejor deshabilitarlo según he leido) y
TCP/IP habilitado, y dentro de las propiedades de TCP/IP está:
Escuchar todo: Sí
Habilitado: Sí
Mantener conexión: 30000
Sin retraso: No

Según he estado leyendo, veo que el 30000 es el tiempo en milisegundos
que SQL Server permite que una conexión esté inactiva, lo cual me deja
una duda, si sólo son 30 segundos, entonces, en cualquier aplicación
normal, ¿un usuario no se puede quedar quieto 30 seg? :D

¿Qué valor tenéis normalmente especificado aquí? Entiendo que 0 es que
no compruebe y que no es recomendable, así que ¿qué valor recomendáis?
Si le pongo 0 un par de días para probar si el error viene por aquí,
creeis que habrá algún problema.

Salu2 y gracias,

Siga el debate

14 respuestas

Tengo una respuesta

Preguntas similare

No cierra la Conexion... + Sql Server

Leer las respuestas

#6 Eclat

03/07/2007 - 20:22 | Informe spam

Ok, acabo de cambiarlo, mañana os comento si se soluciona el problema.
¿Este cambio tiene algún efecto secundario conocido?

Maxi escribió:

exacto

Responder a este mensaje

#7 Isaias

04/07/2007 - 00:44 | Informe spam

Aunque mejore (no lo se), insisto, no es la mejor forma de hacer una conexion
a la base y mantenerla abierta siempre.

Logicamente, ¿para que tener una conexion abierta cuando no se usa?
Saludos
IIslas

"Eclat" wrote:

Ok, acabo de cambiarlo, mañana os comento si se soluciona el problema.
¿Este cambio tiene algún efecto secundario conocido?

Maxi escribió:
> exacto
>

Responder a este mensaje

#8 Maxi

04/07/2007 - 01:15 | Informe spam

Hola Isaias, que no sea una buena practica tener una conexion abierta por
mucho tiempo no quita que esta se deba desconectar solar, con lo cual no
podemos atribuir que el problema es tener la conexion abierta, antes de
ADO.NET era mas comun mantener una conexion abierta y trabajar en un mundo
mas conectado, con ADO.NET se ha utilizado mas el concepto de ambientes
desconectados y usar solamente cuando lo necesito. Ahora bien, hay miles de
aplicaciones que mantienen la conexion abierta hasta que el usuario las
cierre y no se desconectan sola y han funcionado por mucho tiempo y bien,
que ahora digamos que no sea la mejor opcion no quiere decir que todo lo que
esta no es util.

-
Microsoft M.V.P en SQLServer
SQLTotal Consulting - Servicios en SQLServer
Email:
"Isaias" escribió en el mensaje
news:

Aunque mejore (no lo se), insisto, no es la mejor forma de hacer una
conexion
a la base y mantenerla abierta siempre.

Logicamente, ¿para que tener una conexion abierta cuando no se usa?
Saludos
IIslas

"Eclat" wrote:

Ok, acabo de cambiarlo, mañana os comento si se soluciona el problema.
¿Este cambio tiene algún efecto secundario conocido?

Maxi escribió:
> exacto
>

Responder a este mensaje

#9 Eclat

04/07/2007 - 09:23 | Informe spam

Con respecto a esto de programar las aplicaciones. Imaginemos lo
siguiente. Presentamos en una GRID (rejilla, tabla, como queráis
llamarle) una serie de datos de una tabla. Para obtener dichos datos,
conectamos a la base de datos, abrimos la tabla correspondiente y
navegamos por los diferentes registros, en este momento la conexión está
abierta. El usuario va actualizando, borrando, modificando, etc, etc,
etc, se levanta de su silla, va a tomar un café y vuelve para continuar
con su trabajo. Lo lógico (aunque no lo óptimo) es que la conexión siga
abierta para que cuando vuelva pueda continuar, ¿no?

¿Hay algún acercamiento que no esté viendo yo correctamente que nos
permitiera ir cerrando la conexión? ¿Con la técnica el "maletín"? ¿Me
traigo todo a un tabla en memoria, actualizo y vuelco los cambios? ¿Y si
varios usuarios han hecho lo mismo?

Lo comento porque a lo mejor estáis más puestos en el tema y os
habéis encontrado con esto miles de veces. No es mi caso :D

Salu2 y gracias por la ayuda, hoy a última hora os contaré como ha ido,

Maxi escribió:

Hola Isaias, que no sea una buena practica tener una conexion abierta por
mucho tiempo no quita que esta se deba desconectar solar, con lo cual no
podemos atribuir que el problema es tener la conexion abierta, antes de
ADO.NET era mas comun mantener una conexion abierta y trabajar en un mundo
mas conectado, con ADO.NET se ha utilizado mas el concepto de ambientes
desconectados y usar solamente cuando lo necesito. Ahora bien, hay miles de
aplicaciones que mantienen la conexion abierta hasta que el usuario las
cierre y no se desconectan sola y han funcionado por mucho tiempo y bien,
que ahora digamos que no sea la mejor opcion no quiere decir que todo lo que
esta no es util.

Responder a este mensaje

#10 Maxi

04/07/2007 - 19:12 | Informe spam

Hola bueno yo no comparto lo que indicas, deberias pensar tus aplicaciones
en un ambiente desconectado, entonces

1) Lleno el dataset con lo que necesito
2) Pongo en la grilla el dataset
3) Aplico los cambios al dataset
4) Me conecto
5) Genero todos los cambios en la base de datos
6) Me desconecto

-
Microsoft M.V.P en SQLServer
SQLTotal Consulting - Servicios en SQLServer
Email:
"Eclat" escribió en el
mensaje news:

Con respecto a esto de programar las aplicaciones. Imaginemos lo
siguiente. Presentamos en una GRID (rejilla, tabla, como queráis llamarle)
una serie de datos de una tabla. Para obtener dichos datos, conectamos a
la base de datos, abrimos la tabla correspondiente y navegamos por los
diferentes registros, en este momento la conexión está abierta. El usuario
va actualizando, borrando, modificando, etc, etc, etc, se levanta de su
silla, va a tomar un café y vuelve para continuar con su trabajo. Lo
lógico (aunque no lo óptimo) es que la conexión siga abierta para que
cuando vuelva pueda continuar, ¿no?

¿Hay algún acercamiento que no esté viendo yo correctamente que nos
permitiera ir cerrando la conexión? ¿Con la técnica el "maletín"? ¿Me
traigo todo a un tabla en memoria, actualizo y vuelco los cambios? ¿Y si
varios usuarios han hecho lo mismo?

Lo comento porque a lo mejor estáis más puestos en el tema y os habéis
encontrado con esto miles de veces. No es mi caso :D

Salu2 y gracias por la ayuda, hoy a última hora os contaré como ha ido,

Maxi escribió:

Hola Isaias, que no sea una buena practica tener una conexion abierta por
mucho tiempo no quita que esta se deba desconectar solar, con lo cual no
podemos atribuir que el problema es tener la conexion abierta, antes de
ADO.NET era mas comun mantener una conexion abierta y trabajar en un
mundo mas conectado, con ADO.NET se ha utilizado mas el concepto de
ambientes desconectados y usar solamente cuando lo necesito. Ahora bien,
hay miles de aplicaciones que mantienen la conexion abierta hasta que el
usuario las cierre y no se desconectan sola y han funcionado por mucho
tiempo y bien, que ahora digamos que no sea la mejor opcion no quiere
decir que todo lo que esta no es util.

Responder a este mensaje

Ads by Google

Hacer una preguntaSiguiente

Tengo una respuesta

1 2 3

Busqueda sugerida