Nueva version Visual Foxpro

[Diacrisa]

Hola a toda la comunidad.

Yo programo en Visual Foxpro.

No soy experta pero me gusta programar en Foxpro.

Me gustaría saber si existe actualizaciones que instale y mejore el rendimiento de visual foxpro 9.0 sp2

Agradecería alguien me de una buena respuesta.

[Douglas Sánchez]

Hola,  Si te refieres velocidad, no he visto algo mas rápido que VFP, ahora que estoy en .Net, veo que nada corre como el Zorro,  deberías revisar tu código fuente a ver que pasa, si esta lenta tu app.

Si te referias a hacer un mejor uso del Hardware, si no usas ningún Activex Control, puede aplicar a esto: http://www.baiyujia.com/vfpadvanced/f_vfpa_history.asp

Los ultimos Hotfix de vfp estan publicado en el foro, pone hotfix vfp2:  Ojo, no son correcciones de rendimiento, solo de ciertos bugs.

Saludes

[Fernando D. Bozzo]

Hola:

Hace ya varios años que dejaron de publicarse parches.

La única forma de mejorar el rendimiento de cualquier aplicación (en cualquier lenguaje) es conocer bien el lenguaje y aplicar las mejores prácticas del mismo.

Te dejo un ejemplo simple, pero muy repetido:

* Única forma en que se podía hacer en dBase:

APPEND BLANK
REPLACE campo1 with valor1
REPLACE campo2 with valor2

* Forma más eficiente actual:

INSERT INTO tabla (campo1, campo2) VALUES (valor1, valor2)

Un ejemplo más:

* Única forma en que se podía hacer en dBase:

GO TOP
DO WHILE NOT EOF()
   (hacer algo)
   SKIP 1
ENDDO

* Forma más eficiente actual:

SCAN
   (hacer algo)
ENDSCAN

Y como esto, muchas cosas más. Lo importante es conocer bien el lenguaje y saber qué es lo más eficiente en cada situación. No existe ningún parche ni nada que mejore el estilo de programación.


Saludos.-

[Carlos Miguel FARIAS]

Complementando lo que indica Fernando.

Como acelerar Fox.

Reducir al máximo la cantidad de comandos utilizados por una operación.

A los ejemplos que dio Fernando, se puede aplicar con el reemplazo de 

SEEK, luego IF FOUND() con IF SEEK()

Tratar de no cambiar de área para acceder a tablas (cambios mínimos, p.e. p/SCAN)

Tratar de no activar índices (SEEK permite indicar una tabla diferente a la actual, ninguna sentencia de SQL necesita indicar indice a utilizar, es más un indice activo perjudica casi siempre el desempeño).

Si se accede a más de una tabla a la vez en un comando, RUSHMORE solo trabaja con SQL. (SELECT, UPDATE, etc.)

Minimizar la cantidad de indices definidos para gestionar la tabla, sobre todo si se está modificando. En VFP, los autoincrementales son notoriamente lentos.

Si se necesita acceder repetidamente a contenidos de tablas pequeñas, conviene levantar las a un arreglo (los cursores en general crean archivos temporarios por lo que casi siempre van a parar al disco) y usar ascan() sobre los arreglos

Lo que se debe tratar siempre es minimizar las operaciones en disco, sobre todo si son remotos.

Usar expresiones de nombre en lugar de macrosustitución, en realidad, usar macrosustitución si realmente no hay otra forma.

Luego las generales de programación.

En una sentencia IF compuesta, si las condiciones se relacionan con AND, poner primero la condición que menos se cumple, como la evaluación se corta no bien el IF se define, al no cumplirse la primera, ya no evalua el resto (una que no se cumple, ya no se cumple el if).

Caso contrario es si las condiciones se relacionan con OR, primero se pone la que más se cumple (con una que se cumpla el if se cumple y no pregunta por las otras)

Esta lógica de los IF también aplica a cualquier lugar donde se hagan evaluaciones lógicas (WHERE, WHILE, FOR <- que no sea bucle).

Si tienes un DO CASE, funciona como las OR, entonces los primeros CASE van con las que más se cumplan.

Con bucles, todo calculo que no se modifica dentro de un bucle, debe ponerse adelante del bucle.

La clausula WITH thisalgo ENDWITH acelera las operaciones dentro (ojo, un return desde dentro de un WITH puede producir "planches" del programa aleatoriamente").

En general: Lo mas lento en una aplicación es la interfaz con el usuario, la "barras de progreso", suelen consumir más tiempo que el proceso de datos del cual pretender mostrar el avance (mejor, crear un gif animado que muestre que se está procesando).

Luego sigue en lentitud el acceso a través de la red (configurar archivos locales). En caso de tablas pequeñas, relativamente estables (no se modifican), conviene tenerlas en el disco local (ya sea por copia o por crear un cursor al inicio).

Luego el cuello de botella son las operaciones con disco. Reducir la cantidad de indices, el tamaño de los campos e indices es un tema mucho mas largo que todo lo desarrollado hasta aquí.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe

[arti...@gmail.com]

Yo estoy pensando en adaptar mi aplicación para el uso de este nuevo formato del 'insert into...' pero tengo una duda.

Actualmente, mi aplicación usa base de datos nativa, la base de datos se abre al iniciarse la aplicación y posteriormente cada form tiene sus respectivas tablas de la

base de datos en el dataenviroment de cada uno. Se abre automáticamente, ¿ Cómo afecta eso usando una base de datos com MySQL ?. 

cada tabla se ha de abrir por separado o actúa igual que las tablas dbf que las pones en el dataenvironment y se abren solas al ejecutar el form ?.

En los procesos de actualización de datos, el usar 'INSERT INTO ....' implica que se inserta un nuevo  registro con los valores de los campos pero si más adelante

quieres añadir información en otros campos de la misma tabla cómo lo haces ?. Supongo que será con algún 'update' o algo así. Estoy un poco perdido sobre el tema.

[Patricio Muñoz]

artigest

Si cambias de base de datos, tienes que hacer todo un cambio en tu forma de abrir, consultar y grabar tablas. Sin embargo se puede usar insert.... into con tablas DBF.

Bendiciones amigo

--

Patricio Muñoz

Pro&Tech

Analista en Sistemas

[arti...@gmail.com]

Una duda que tengo es, si tengo que abrir todas las tablas de una vez, ó solo las que necesite en cada momento como hago ahora con la base de datos nativa y

otra gran duda, ¿ VFP sigue respetando que los entornos de datos son en los forms y los propios forms los entornos de datos estén en sesiones privadas de datos ?

El domingo, 7 de agosto de 2016, 16:59:01 (UTC+1), Diacrisa escribió:

[Víctor Hugo Espínola Domínguez]

Debes olvidarte del concepto "abrir/cerrar" tablas, piensa en conexiones: Necesita mi formulario estar permanentemente "conectado" a la base de datos? o debe "conectarse/desconectarse" según la necesidad de acceder a los registros? Esa decisión depende de varios factores, generalmente el esquema "conexión/desconexión" es conveniente.

Los formularios no necesitan acceder a tablas, deben solicitar/enviar datos a la capa de reglas de negocio y manejar esos datos en cursores, objetos, arrays o colecciones. Las instrucciones APPEND, REPLACE, DELETE se pueden efectuar sobre cursores, pero es preferible usar los comandos SQL. Los datos van a la base de datos a través de la capa de negocios, previa validación.

Si la sesión de datos del formulario debe ser privada o no depende de si se permite o no más de una instancia del formulario y de algunas otras consideraciones de cada caso en particular.

http://fdbozzo.blogspot.com/2014/10/vfp-la-interfaz-las-reglas-de-negocio-y.html

Adjunto un ejemplo sencillo de ABM en 3 capas, cambia la extensión a 7z.

Saludos,

Víctor.

Lambaré - Paraguay.