OLEDB y Timeout

Si trabajas con OLEDB, te interesa conocer estos dos valores para la cadena de conexión:   WD Connection Timeout    WD Command Timeout

En el enlace: https://help.windev.com/?9000124&name=optional_connection_information  explican su uso.

Estaba teniendo un problema con SQL Server, ya que tengo un SQL que inserta 400.000 registros con un INSERT SQL ….. SELECT otra tabla,   y en la ejecución en LOCAL me tarda entre 25-30 segundos.  A veces me funcionaba bien pero otras veces, me daba error de TIMEOUT y no se ejecutaba.  Cuando lo ejecuto contra el servidor de producción, el tiempo se va a 50-60 segundos y SIEMPRE me da error de TIMEOUT.

Windev, por defecto tiene establecido 30 segundos de espera para la ejecución de comandos SQL para conexiones nativas o por OLEDB, y si la instrucción dura más de 30 segundos, la cancela.

La forma de solucionarlo, es usar “WD Command Timeout=xxxxx” segundos en la cadena de conexión.

Le he puesto “WD Command Timeout=3600” (una hora) y …. ¡FUNCIONA!  J, ahora las consultas grandes que duran 1-3 minutos se ejecutan sin problemas.

Tipo de Dato RECORD que permite hacer SCATTER y GATHER (como en Fox)

/////////////////////////////////////
// Ejemplo para insertar un registro
////////////////////////////////////

rgCondMod1 is Record of condiciones_modificaciones

// Inicializamos los valores, Similar a un SCATTER MEMVAR de Fox

HReset(rgCondMod1)

// Si quisieramos cargar un registro existente, usaríamos primero: HReadSeek( 
//if hreadseek(condiciones_modificaciones,FKIMPORTA,1) THEN
     // Inicializamos los valores, Similar a un SCATTER MEMVAR de Fox
     // rgCondMod1 = condiciones_modificaciones
//END

// Actualizamos valores

rgCondMod1.FKIMPORTA= 1
rgCondMod1.NTIPOMODI= 2
rgCondMod1.FKIDCONDIC= 3

// Volcamos el registro sobre la tabla, Similar a un GATHER MEMVAR de Fox

condiciones_modificaciones = rgCondMod1

// Insertamos el registro en disco

HAdd(condiciones_modificaciones)

La ventaja de usar un RECORD, es que lo puedes pasar como parámetro entre clases, métodos, etc

Si se necesita una explicación más exhaustiva sobre el paso de parámetros, se puede consultar la ayuda https://ayuda.windev.es/es-ES/?1514077&name=passing_parameters

Para pasar parámetros a una ventana hija,  y que los cambios en ella se vean reflejados en la variable de la ventana padre, no hay que hacer nada especial, se pasan como a cualquier otro proceso.

Siguiendo el ejemplo anterior y teniendo una ventana hija llamada “Win_prueba2”, la llamada se haría así:

Open(WIN_prueba2, rgCondMod1)

En la sección de declaración de la ventana WIN_prueba2 se pondría así:

PROCEDURE WIN_prueba2(rgCondModWin is Record of condiciones_modificaciones)

*- NOTA: No es obligatorio poner el tipo de variable “is Record of condiciones_modificaciones”, pero si se pone, Windev nos ofrece la ayuda en línea para la variable, mostrando el nombre de los campos al poner el “.”

No hace falta devolver ningún valor a la ventana padre, ya que por defecto Windev pasa los parámetros por referencia.  Los cambios que se hagan sobre la variable en la ventana hija se verán reflejados en la variable de la ventana padre.

Si se quiere forzar a que se pasen los parámetros por valor (evitando que los cambios en la ventana hija afecten a la padre), se puede declarar la variable usando el comando LOCAL.  Quedaría así:

PROCEDURE WIN_prueba2(LOCAL rgCondModWin is Record of condiciones_modificaciones)

Como prevenir el error de MySQL para accesos muy repetitivos

El cliente de MySQL  (libmysql.dll 5.x o 6.x)  puede dar error cuando se usa repetitivamente (tal como 1.000 veces) en el mismo proceso. Una forma de evitarlo es colocar la libreria LIBMYSQL dll en el código de inicialización del proyecto, antes de acceder a la base de datos.

sDllMySQL is string = "LibMySQL.DLL"
nInstanceMySQL is int = LoadDLL(sDllMySQL)

IF nInstanceMySQL=0 THEN
   EndProgram("Error al cargar LIBMYSQL", ErrorInfo())
END