mostrar mensaje al hacer un append from

[José Luis Sánchez]

Hola,
En mis programas cuando se lanza un indexado primero regenerlo los ficheros dbf y fpt mediante la creación de un fichero en blanco y copiando los datos del viejo al nuevo. Algo así:

Code: Select all  Expand view

      // platos
      oSay:SetText(i18n("Actualizando fichero de Tipos de Plato"))
      DbCreate(cDir+'pl', {{'PLPLATO'     , 'C',   1,   0} ,;
                           {'PLTIPO'      , 'C',  30,   0} ,;
                           {'PLRECETAS'   , 'N',   5,   0}}, 'DBFCDX' )
      close all
      use &(cDir+'pl') new
      select pl
      if FILE(cDir+'PLATOS.DBF')
         delete file &(cdir+'platos.cdx')
         append from &(cdir+'platos')
         dbcommitall()
         close all
         delete file &(cdir+'platos.dbf')
      endif
      close all
      rename &(cdir+'pl.dbf') to &(cdir+'platos.dbf')
 

El problema es que hay archivos muy grandes, de 15mil registros con campos memo incluidos, parece que el programa se queda congelado aunque está trabajando. Así que me gustaría indicar un mensaje de progreso, algo parecido a lo que se hace al indexar con la clausula EVERY del comando INDEX, pero no se cómo meter ese mensaje en el append from. En la documentación del append from no pone nada de clausula EVERY ni parecido, y la verdad es que no se cómo enfocar esto. No se si con un codeblock se podría, si alguien me puede ayudar lo agradecería.
Saludos,
José Luis

[thefull]

Buenas, yo tuve el mismo problema y lo solucioné con el WHILE del APPEND FROM

Code: Select all  Expand view

static s_nContador_append := 1
static nRegister := 1        
static s_CADA_X_REGISTROS  /* Usado para determinador el METER en el append from*/

Code: Select all  Expand view

                   nRegister := 1
                   s_CADA_X_REGISTROS := INT( nTotalRegistos * 0.05 )/* Cada 5% actualizamos */

                   APPEND FROM ( s_cRuta_Destino + cRuta_Datos + cDbf ) ;
                          WHILE Appendeando( oMeter2 )

                   oMeter2:SetTotal( nTotalRegistos )
                   SysRefresh()

Code: Select all  Expand view

FUNCTION Appendeando( oMeter )

    if nRegister >=  s_CADA_X_REGISTROS
       s_nContador_append  += s_CADA_X_REGISTROS
       oMeter:Set( s_nContador_append  )
       nRegister := 1
    else
       nRegister++
    endif

Return .T.

[José Luis Sánchez]

Gracias Rafa, te las sabes todas.

[José Luis Sánchez]

Hola,
Al final el código ha quedado así:

Code: Select all  Expand view

...
   use &(cDir+'pl') new
   select pl
   if FILE(cDir+'PLATOS.DBF')
      delete file &(cdir+'platos.cdx')
      append from &(cdir+'platos') WHILE Ut_dbfmeter( oProgress, @nProgress )
      dbcommitall()
      close all
      delete file &(cdir+'platos.dbf')
   endif
   close all
...
Function Ut_dbfmeter( oProgress, nProgress )
    local lReturn
    oProgress:SetPos(nProgress++)
    if nProgress == oProgress:nMax
        lReturn := .f.
    else
        lReturn := .t.
    endif
return lReturn
 

y me está pasando una cosa muy curiosa: en XP al regenerar un fichero con 13mil registros con campos memo me tarda 2 segundos, pero con Windows 7 me tarda casi 3 minutos. ¿ Alguien encuentra una explicación a esto ?

Saludos,

[horacio]

En la empresa donde trabajo todos usan xp o vista y el sistema funciona perfectamente, Yo acabo de adquirir una máquina con windows 7 home premium y trabajar en la red resulta imposible. Este mismo sistema lo migré a Mysql y funciona bien en w7. Se me ocurre que no le gusta mucho las dbf's.

[thefull]

A mi me paso en un Servidor W2003 , la aplicación clipper tardaba 10 segundos, la aplicación harbour tarda 5 minutos!!!!! en esa máquina
Estuve mirando todo lo que pude imaginar, toque dios sabe que, y al final , no saque nada claro.
Y era una aplicación en modo consola que solo hace un recorrido por unas tablas y genera un XML., En mi máquina tarda 5 segundos en harbour y es un Win7 64 bits

Me lo he encontrado en un par de sitios más, se quedó como un misterio.

Prueba de hacer la prueba con Clipper, al igual te llevas una sorpresa.

Si resuelves algo , me iluminas.

[Carles]

JL,

Este código és erròneo en cuanto a rendibilidad. Funciona ? -> si, pero quizas en tu sistema y si te limitas a pocos registros no s e apreciara, pero te recomiendo cambies el sistema en un entrono de miles de reg. No puedes hacer un :Setpos() cada vez q proceses x q el sistema lo ralentizas completamente. :Setpos() solo es aconsejable hacerlo como mucho 100 veces

[José Luis Sánchez]

Carles,
Lo pruebo y te comento que tal funciona. En la indexación hago un setpos() del meter por cada registro y no encuentro diferencias entre XP y Win7. Yo creo que el tema viene de que este dbf lleva asociado un fpt y el append... desde el fpt es lo que ralentiza.
¿ Sabeis si hay otra manera de depurar un dbf que borrando y haciendo append from ... ?

Saludos,
José Luis

[Manuel Valdenebro]

¿ Sabeis si hay otra manera de depurar un dbf que borrando y haciendo append from ... ?

Hay otra forma con COPY TO, pero no sé si será más rápida que con APPEND FROM.

Supongamos que quiero depurar el fichero clientes.dbf + clientes.fpt

FERASE ("temp.*") // es un fichero temporal

DBRENAME ("clientes.dbf", "temp.dbf") // renombra la dbf y el memo a temp

USE temp

COPY TO "clientes.dbf" // copia, depurada a la tabla final.

[hmpaquito]

Señores,

En ambos casos, bien APPEND, bien COPY TO, hay que llevar mucho cuidadín porque nos podemos quedar *SIN DATOS*.

Mexplico:

Si en el transcurso del APPEND/COPY se produce un error, entonces habrá pérdida de datos. ¿ cómo es eso ? preguntará alguno, si es muy difícil que haya una caída del sistema ¡ precisamente en ese momento !
Es que el problema que puede aparecer no va por ahí; el problema va más bien por un error en tiempo de ejecución por ejemplo un data width error o similar. Por todo esto hay que "proteger" la operación, bien protegida contra errores y en caso de error que sea la función la que "recupere" la situación inicial, y avise si NO lo pudo hacer para que el usuario reaccione ¡como la pólvora!

Saludos

[José Luis Sánchez]

Carles, reduciendo el número de setpos() el rendimiento mejora, pero sigue habiendo una diferencia de tiempos abismal entre XP y Windows 7.

Manuel, voy a probar esa otra manera, aunque creo que el resultado será parecido.

hmpaquito, tienes razón, por eso no se borra el fichero original hasta el final.

Saludos,

[thefull]

Carles, por eso yo lo aplico por cada % , por un simple tema de rendimiento como dices.
Pero creo que el problema es otro, yo no encontré que puede ser... algo hay que Harbour que penaliza con respecto a Clipper y no se que es