No salir del programa desde ErrSysW

[gmart1]

Hola, estoy intentando solucionar un problema que se me ha dado en un par de clientes cuando están conectados por ADO a una base de datos MySQL en un servidor virtual.

Se producen desconexiones de la base de datos, cuando no hay actividad, así que he pensado modificar ErrSysW de la siguiente forma para capturar el error e intentar que reconecte a la base de datos.

Code: Select all

   cMessage   = "   Error description: " + ErrorMessage( e ) + CRLF
   cErrorLog += cMessage

   if AT ("WINOLE/1007", cMessage) # 0 .and. AT ("(0x800A0CB3)", cMessage) # 0
    M->oAnnos:oADO:CONECTAR ()
    nVeces := 1
    do while nVeces < 5 .and. M->oAnnos:oADO:oCon = Nil
        nVeces++
        M->oAnnos:oADO:CONECTAR ()
    enddo
    if M->oAnnos:oADO:oCon # Nil
        lRet := .t.
        return lRet    // Necesito que no se salga del programa. Actualmente me genera hb_out.log y se sale.
    endif
   endif
 

La variable M->oAnnos:oADO es una instancia de una clase que tengo para encapsular la conexión ADO y cuyo método CONECTAR es el siguiente :

Code: Select all

method CONECTAR ()                      class TAdo

    ::oCon := FW_OpenAdoConnection( { "MYSQL", ::cServer, ::cDataBase, ::cUser, ::cClave }, .t. )
    if ::oCon == Nil
        ? 'Falla'
    endif
return .t.

Lo que necesito es que cuando he reconectado a la base de datos no se salga del programa, como indico en el comentario de la línea "return lRet"

Uso FWH1601, Harbour 3.2 y Bcc 7.0

[karinha]

Click en el boton <Retry> deberia funcionar. Saludos.

[gmart1]

No quiero que al cliente le aparezca el error, el código que he puesto en ErrSysW.prg está en la función ErrorDialog (e) y hago el return lRet antes de que aparezca el diálogo de error.

[karinha]

Se comprendo tu duda:

Code: Select all

   IF .NOT. lRet  // lRet = .F.  muestra el dialogo de erro...

      DEFINE DIALOG oDlg SIZE nDlgW, nDlgH ;
             TITLE DLG_TITLE COLORS CLR_BLACK, CLR_WHITE TRANSPARENT

      oDlg:lTruePixel := .F.
      oDlg:lHelpIcon  := .F.

      @ 0, 20 SAY oSay PROMPT OemToAnsi( cMessage ) ;
        CENTERED OF oDlg FONT oFont SIZE 400, 20 COLORS CLR_HRED, CLR_WHITE

      ...

   ELSE
      ...

   ENDIF
 

Saludos.

[armando.lagunas]

primero que nada ejecuta esta instrucción para la sesión mysql aumentando el tiempo de espera:

Code: Select all

oConn:Execute("SET SESSION wait_timeout = 86400;" )

PD: el mismo problema me afectaba, pero yo me conecto a la db por ODBC, tuve que modificar la clase original tOdbc.prg para que capturar el error de perdida de conexión y realizar una nueva conexión a la misma antes que saltase ErrSysW.

[gmart1]

Gracias karinha por contestar, pero no me has entendido.

Quiero que después de producirse un error por la desconexión a la base de datos a través de ADO, el programa no termine. Poder recuperar el error para reconectar a la base de datos y continuar la ejecución del programa.

Creo que lo que necesito no es posible, porque cuando se produce un error de este tipo siempre se termina la ejecución del programa y no hay forma de continuar.

He buscado en el foro y he encontrado esta entrada http://forums.fivetechsupport.com/viewt ... =ADO+state

Con la función IsCnActive voy a detectar que se ha producido una desconexión y reconectaré con la base de datos, el problema es que tendré que controlarlo en todas las partes del programa que accedan a la base de datos.

[gmart1]

primero que nada ejecuta esta instrucción para la sesión mysql aumentando el tiempo de espera:

Code: Select all

oConn:Execute("SET SESSION wait_timeout = 86400;" )

PD: el mismo problema me afectaba, pero yo me conecto a la db por ODBC, tuve que modificar la clase original tOdbc.prg para que capturar el error de perdida de conexión y realizar una nueva conexión a la misma antes que saltase ErrSysW.

Gracias Armando, intentaré aumentar el timeout, pero pensaba que ese valor lo establecía el servidor de la base de datos y no la sesión del cliente.
De hecho tengo otros clientes que se conectan al mismo servidor y no se producen desconexiones. Pueden estar varias horas conectados.
Mis sospechas van encaminadas al proveedor de la ADSL, porque al último cliente que le ha empezado a dar problemas ha sido desde que cambió de proveedor.