Migracion a Harbour

[Carlos Mora]

Entiendo que te refieres a Viktor. Przemek no aparece en el hilo.

Tienes razón, me lié porque fue Przemek quien me lo explicó en su momento y como se hacía.

Por otra parte. Imagínate un extracto de artículos vendidos a todos los clientes. Estando sobre una linea, pulsas y te muestra un nuevo extracto con los articulos vendidos al cliente de la linea. Ahí hay reentrada, incluso en modo ST. El uso de static en esas condiciones dará lugar a errores, sino se lleva cuidado.

Me parece que no es el tipo de reentrada al que se refiere el problema con las STATICs, independientemente del cuidado que hay que tener en la programación de cosas expuestas a eventos como es la programación en Windows. Los problemas de alto nivel se pueden superar con buena programación, los de bajo nivel son significatívamente más complejos.

PD 2. Ya tengo en marcha la exportacion mysql rapida y desatendida solo con codigo prg.

¿Y que pasa que no nos lo cuentas? Jaja.

Justamente en este momento me encuentro haciendo algo parecido: traspasar los datos de unas dbfs al servidor MySQL a medida que se escribe la aplicación nueva y se van usando los dos sistemas en paralelo. Sincronizar una tabla de pacientes es algo así como:

Code: Select all  Expand view

   WITH OBJECT oPacientes:= TModel():New( oServer, 'pacientes' )
      USE (cDirData+'paciente.dbf' ) SHARED READONLY NEW
      GO TOP
      WHILE !Eof()
         IF :GetById( Field->NroPac )
         ELSE
            :Blank()
            :Id:= Field->NroPac
         ENDIF
         MsgWOn( 'Paciente '+Field->NroPac ) // Esto es para ir mostrando que registro estoy actualizando
         :FromWorkArea()
         // Las fechas vacías tienen que ir como NIL sino casca.
         IF Empty(Field->FecAnam)
            :FecAnam:= NIL
         ENDIF
         IF Empty(Field->VtoCarnet)
            :VtoCarnet:= NIL
         ENDIF
         
         
         IF !:Update()
            MsgAlert( 'Error al sincronizar: '+oServer:ErrorMessage())
            QUIT
         ENDIF

         SKIP
      ENDDO
   END

 

La clase TModel se encarga de enviar solo lo que realmente cambia, con lo que minimiza los cambios y si no se actualiza nada no me modifica el timestamp 'updated_at' en el MySQL.

[hmpaquito]

Me parece que no es el tipo de reentrada al que se refiere el problema con las STATICs, independientemente del cuidado que hay que tener en la programación de cosas expuestas a eventos como es la programación en Windows. Los problemas de alto nivel se pueden superar con buena programación, los de bajo nivel son significatívamente más complejos

Sí, es otro tipo de reentrada, que a mi, al menos, se me ha dado un buen numero de veces, que se suma a la otra reentrada del hilo que enlacé anteriormente.

¿Y que pasa que no nos lo cuentas?

Deseando estaba que alguien preguntara

El plan ha sido hacer algo parecido a lo que tenia en las imagenes: hacer subidas de datos incrementales, en román paladino: subir solo lo que ha cambiado.
Pero como me disgusta tener que hacer procesos que abarcan todo el programa, es decir, tener que buscar alla donde se modifican las tablas, pensé el siguiente, que creo recordar que ya sugerí en el hilo que llevábamos a medias de este tema:

Se crea IncrementalQuerys.dbf con campos:
Comando C 15 // INSERT / DELETE
Codigo C 40 // Parte SET cuando INSERT, parte WHERE si DELETE
Asignacion M 10 // Sólo Comando INSERT: Parte ON DUPLICATE KEY UPDATE

Y con indice Comando+ Codigo.

Justo en el momento de ejecutar el query, se busca si existe SEEK y si existe, se compara con el campo Asignacion existente.

Entre enviar solo los datos relevantes más hacerlo de forma incremental, he bajado de 480.000 querys a solo 134 diarios, dicho de otra forma de 50 horas de traspasos a 3 minutos, y sobre todo - sobre todo, centralizado en la rutina de exportacion

Saludos