componente no libera id procesos en el SQL

En el destroy de la clase

WITH THIS
IF .lDescon
SQLDISCON(.nCon)
ENDIF
ENDWITH

Gracias por vuestros comentarios



"Roka" escribió en el mensaje
news:%

veo el this.nCon pero donde haces la desconexión?

"Fernando Jimenez Cantalapiedra" wrote in
message news:

Gracias por vuestras observaciones.
Volveremos a revisar el componente en los procesos de acceso a base de
datos. Por lo norma, solemos seleccionar un area nueva y cerrarla antes
de finalizar el metodo.
El problema es porque lleva 4 años en explotacion y funcionaba bien
(destruyendo los id_procesos). ¿Donde se puede ajustar el numero de
sesiones concurrentes en SqlServer o la relacion de estas con la
memoria?

cSQL = "SELECT xxx FROM TARI_HISTNIVEL "
old_Al = SELECT()
SELECT 0

IF SQLEXEC(THIS.nCon, cSQL) > 0 AND RECCOUNT() > 0

RELEASE cSQL
SCAN
XXXXXXX.
ENDSCAN
USE
SELECT (old_Al)

Un saludo y gracias de nuevo.

"Jhonny Vargas P." escribió en el
mensaje news:

Exacto... revisa en la COM+ que no está la opción de que requiere una
transacción...

Saludos,
Jhonny Vargas P.
http://msmvps.com/jvargas
Santiago de Chile

"Gux (MVP)" escribió en el mensaje
de noticias:

Personalmente empezaría por revisar esos componentes COM+ que parecen
estar
dejando sesiones abiertas.

Gustavo Larriera, Microsoft MVP
http://www.linkedin.com/in/gustavolarriera
Este mensaje se proporciona tal como es, sin garantías de ninguna
clase.



"Fernando Jimenez Cantalapiedra" wrote:

Hola compañeros,
Desde el jueves tenemos una incidencia que nos esta comiendo la
moral.
Tenemos un componente desarrollado en VFP6, instalado en el Com+ de
un
W2000. En el mismo servidor tenemos un IIS5 donde estan las paginas
que van
contra el componente. Por otro lado un SQLServer donde accede esta
aplicacion.
Todo funcionaba correctamente, hasta el jueves. Lo unico que hemos
podido
ver es que los id_procesos del SQL no se liberan y se van
acumulando...hasta
que casca.
¿Habeis tenido alguna incidencia del estilo?¿por donde podria
continuar
mirando?

Saludos y gracias

y porqué no prueba haciéndolo inmediatamente después de la consulta?
después del exec ya no ocupas la conexión.
yo tenía el mismo problema y lo arreglamos de esa manera.

"Fernando Jimenez Cantalapiedra" wrote in
message news:

En el destroy de la clase

WITH THIS
IF .lDescon
SQLDISCON(.nCon)
ENDIF
ENDWITH

Gracias por vuestros comentarios



"Roka" escribió en el mensaje
news:%

veo el this.nCon pero donde haces la desconexión?

"Fernando Jimenez Cantalapiedra" wrote in
message news:

Gracias por vuestras observaciones.
Volveremos a revisar el componente en los procesos de acceso a base de
datos. Por lo norma, solemos seleccionar un area nueva y cerrarla antes
de finalizar el metodo.
El problema es porque lleva 4 años en explotacion y funcionaba bien
(destruyendo los id_procesos). ¿Donde se puede ajustar el numero de
sesiones concurrentes en SqlServer o la relacion de estas con la
memoria?

cSQL = "SELECT xxx FROM TARI_HISTNIVEL "
old_Al = SELECT()
SELECT 0

IF SQLEXEC(THIS.nCon, cSQL) > 0 AND RECCOUNT() > 0

RELEASE cSQL
SCAN
XXXXXXX.
ENDSCAN
USE
SELECT (old_Al)

Un saludo y gracias de nuevo.

"Jhonny Vargas P." escribió en el
mensaje news:

Exacto... revisa en la COM+ que no está la opción de que requiere una
transacción...

Saludos,
Jhonny Vargas P.
http://msmvps.com/jvargas
Santiago de Chile

"Gux (MVP)" escribió en el mensaje
de noticias:

Personalmente empezaría por revisar esos componentes COM+ que parecen
estar
dejando sesiones abiertas.

Gustavo Larriera, Microsoft MVP
http://www.linkedin.com/in/gustavolarriera
Este mensaje se proporciona tal como es, sin garantías de ninguna
clase.



"Fernando Jimenez Cantalapiedra" wrote:

Hola compañeros,
Desde el jueves tenemos una incidencia que nos esta comiendo la
moral.
Tenemos un componente desarrollado en VFP6, instalado en el Com+ de
un
W2000. En el mismo servidor tenemos un IIS5 donde estan las paginas
que van
contra el componente. Por otro lado un SQLServer donde accede esta
aplicacion.
Todo funcionaba correctamente, hasta el jueves. Lo unico que hemos
podido
ver es que los id_procesos del SQL no se liberan y se van
acumulando...hasta
que casca.
¿Habeis tenido alguna incidencia del estilo?¿por donde podria
continuar
mirando?

Saludos y gracias