Errores comunes en Microsoft Visual FoxPro

25/03/2020 Actualizado 09/01/2025

Autor: Espartaco Palma Martínez

 

Microsoft Visual Foxpro ha sido a través de los años una herramienta de desarrollo de aplicaciones para el manejo de bases de datos, esto ha atraído a muchos profesionales interesados en este rubro, tanto noveles, como expertos en otras herramientas. A veces es difícil acostumbrarse a un nuevo entorno y manera de trabajo, es por eso que se cometen errores de principiantes, los cuales, a veces no son tan obvios. Este documento está basado en experiencia personal y de grupo, se apoyó en la documentación encontrada en el FoxWiki:
http://fox.wikis.com/wc.dll?Wiki~VFPRookieMistakes

 

Introducción

Al pasar de los años, los lenguajes no visuales empezaron a entrar en desuso, y/o también a mostrar sus limitaciones, no estoy diciendo que no sirvan, simplemente que empezaron a verse que tanto no se podía hacer con ellos, además de que no iba con los estándares mundiales de desarrollo como lo pueden ser los MDI (Multiple Document Interface) o SDI (Single Document Interface), por tal motivo, muchos profesionales en el desarrollo de aplicaciones buscaron un nuevo entorno para crear sus sistemas de información, es decir, vino un incremento considerable de personas que pasaron de un lenguaje tipo x-Base hacia lenguajes visuales como lo es Visual FoxPro.

La curva de aprendizaje desde lenguajes x-Base hacia lo que es uno orientado a objetos es bastante alta; Visual FoxPro ha sido una herramienta que ha dado la posibilidad de migrar con la menor cantidad de cambios en la forma de trabajo, pero a su vez ofrece la posibilidad de hacer actualizaciones que mejoren el desempeño de sistemas heredados o “Legacy Sistems”.

Este documento está orientado hacia aquellas personas que cambian de un lenguaje tipo x-Base, quienes van iniciando en el desarrollo de sistemas y también profesionales de otras herramientas que no es propiamente Visual FoxPro. No es la intención dar cátedra sobre Ingeniería de Software, o sobre Métodos de Programación, sino solo remarcar las cosas que generalmente por “comodidad” o por desconocimiento se hacen de una manera incorrecta y/o errónea.

Hablaremos sobre cómo evitar de manera eficiente los errores “clásicos” que se cometen cuando iniciamos (debemos aceptarlo, todos alguna vez tuvimos errores de novato), las cosas que no usamos porque se nos ha hecho muy cómodo hacerlo de la manera “antigua”, y también las cosas que no deberíamos hacer con la herramienta, como por ejemplo: exagerar en el uso de prestaciones que ofrece Visual FoxPro para querer hacer “todo”, cada cosa en su lugar y un lugar para cada cosa.

 

Errores comunes

  • Utilice READ EVENTS y CLEAR EVENTS

    Uno de los post mas comunes dentro de los grupos de noticias de Visual FoxPro (VFP) es uno relativo a que su aplicación “Aparece y Desaparece” cuando trata de ejecutar su .EXE, mas no sucede desde dentro del entorno de VFP.

    READ EVENTS sirve para decirle a VFP que empiece a procesar los eventos programados en el .EXE, sin él, VFP simplemente ignora esos eventos, ocasionando que nuestros desarrollos se activen y desactiven casi inmediatamente.

    CLEAR EVENTS es para el caso contrario, cuando deseemos que se dejen de procesar los eventos del programa, es decir, se “termine” el programa deberíamos utilizar dicho comando.

  • Revise el estado de SET EXCLUSIVE

    Por default el valor de SET EXCLUSIVE es ON, así cuando se crea un ejecutable (.EXE) sin decirle explícitamente que lo cambien, lo que obtendrás será un sistema que no será muti-usuarios.

    Hay que hacer notar que para sesiones privadas de datos su valor por default es OFF.

  • Revise el estado de SET DELETE

    Más que un error, es una falla que permite que nuestros desarrollos hagan cosas “indebidas” o que no se esperaba que hicieran, su estatus tendrá impacto directo en el desempeño de las aplicaciones, el estado recomendado es ON, de esta manera no se procesarán los registros marcados como borrados. Tómese el tiempo de revisar que comandos son afectados por esta configuración.

  • Tenga cuidado con los Settings en cada DataSession

    Quizás hayan leído en la ayuda “Esta configuración tiene alcance a la sesión de datos actual”, muy bien, pero ¿Que significa?, quiere decir que dicho Setting regresa a su valor por defecto en cada sesión de datos privada, por ejemplo, SET SAFETY está en ON por default, si en algún lugar pusiste SET SAFETY OFF, tendrás que reestablecerlo cada que abras una nueva sesión de datos.

  • Evite utilizar palabras reservadas

    No es muy buena idea utilizar las palabras reservadas como nombres de variables o de campos de tablas, aunque VFP te lo permitiera hacerlo, las consecuencias podrían ser bastante inesperadas. Por ejemplo, nombra una variable “PACK” y utilizarla en una asignación provocaría la llamada al comando PACK. Otra cosa que no desearía ver sería una sentencia SQL de este modo:

    • SELECT * FROM cTabla ;
    GROUP BY group ;
    ORDER BY order ;
    INTO CURSOR cursor

  • Tablas sin registros

    Prueba tu aplicación contra su disponibilidad de trabajar con tablas sin registros, punteros de registros al final del archivo, así como grandes cantidades de registros. Podría ser bastante engorroso tener que ir al sitio de tu cliente, sólo para ir a darle un INSERT INTO miTabla VALUES (x,y,z)

  • Cardinalidad de Vectores/Arreglos/matrices (Arrays)

    No deberías presuponer que ese arreglo que hace maravillas con los cálculos hacia tus tablas tendrá siempre los elementos que se supone debería tener, eso es un error, quizás en tus pruebas siempre tuvo por ejemplo 6 elementos, por que te dijeron que siempre sería así, ¿Haces previsiones sobre eso?, ¿no?, entonces ¡deberías!, por lo general casi todas las funciones que tienen que ver con “generar” arreglos obtenidos de algún lado, retornan el número de elementos que se agregaron a dicho arreglo, como un ejemplo de ello tenemos lo siguiente:

 

 Mal codificado
 

ADIR(laMiArreglo,”*.ptx”)

FOR I=1 to 6

?laMiArreglo[i,1]

ENDFOR

 
 Recomendado
 

LnElementos = ADIR(laMiArreglo,”*.ptx”)

FOR I=1 to lnElementos

?laMiarreglo[i,1]

ENDFOR

 
  • Segmentos condicionales

    A pesar de que sólo uses IF ... ENDIF y “nunca” habrá un ELSE, no lo predispongas, considera el uso de las clausulas ELSE para aquellos casos que no tuvieras contemplados, lo mismo para DO CASE ... ENDCASE, utilizar OTHERWISE. Recuerda, uno “nunca” sabe <g>.

  • No utilice los archivos de recursos.

    A menos de que tu aplicación tome ventaja de alguna característica especial de los archivos de recurso de VFP (FoxUser), agrega la linea RESOURCE = OFF en el archivo config.fpw de tu desarrollo; estos archivos normalmente no son utilizados y a la vez dan muchos problemas cuando se corrompen, claro, es fácil borrarlos y dejar que se creen solos, pero creo que no hay necesidad de que ni tu, ni tu cliente gasten el tiempo en pequeñeces sin importancia. Así que si no lo necesitas, no lo uses.

  • Evita errores con equipos sin impresoras instaladas.

    Otro error común es pensar que siempre habrá una impresora instalada en el equipo, puede que no sea así, por lo que es una buena decisión el hacer antes una revisión de impresoras utilizando APRINTERS(). De otra manera, si se ejecuta un:

 REPORT FORM miReporte NOCONSOLE TO PRINTER
 

    lanzará un error indicando que no existen impresoras instaladas, considero que no hay necesidad de pasar ese pequeño inconveniente.

  • Use el Debugger de VFP

    ¿Te faltó analizar alguna operación?, ¿no tienes idea de que pasó?, no te preocupes, no pasa todo el tiempo, pero cuando pase, toma un respiro y utiliza esta herramienta que nos facilita VFP, con ella podrás revisar los valores de las variables, si están creados esos objetos, si tu propiedad “especial” tiene ese valor que esperabas, date una vuelta por esos lados utilizando lo que prefieras SET STEP ON ó en su defecto SUSPEND.
    No te olvides también usar DEBUGOUT y ASSERT.

  • Errores comunes con datos y base de datos

    Relaciones persistentes en contenedores de Base de Datos (DBC).

    No es lo mismo que establecer la relación con SET RELATION, las relaciones persistentes son usadas para usuarse como JOIN por defecto en el Diseñador de Consultas y Vistas, para almacenar información sobre integridad referencial y en general para hacer un poco mas fácil el trabajo con VFP. Revise en la ayuda para mas información.

  • REPLACE no actualiza todos los registros

    Cuidado con este comando, se ve afectado por la configuración de SET ORDER y SET FILTER, puede que tarde tiempo en detectar que eso es lo que está haciendo que las cosas funcionen mal. Si necesita actualizar todos los registros sin importar esos settings guarda antes esas configuraciones, restablecerlos al terminar.

 

LcOldFilter = SET(“FILTER”)

SET FILTER TO

REPLACE foo WITH foovalue ALL

SET FILTER TO &lcOldFilt

 
  • Utilice todos los parametros de TableUpdate()

    TableUpdate() puede tomar 3 o 4 parámetros, usa todos, pueden servir para evitar muchos errores. Los parámetros son:

    1.- ¿Que registros actualizar?

    • 0 = Solo el registro actual
    • 1 = Los registros pendientes, falla si algun registro faltó actualizar
    • 2 = Los registros pendientes, si algun registro falla continua con el resto y pone el numero de registro fallido en el array especificado en el 4to argumento.
     

    2.- Forzar la grabación (si .T. grabará los registros sin importar, .F., fallará la operación si otro usuario ha hecho cambios).

    3.- El Alias con el cual trabajar.

    4.- Nombre del arreglo donde se guardará el número del registro que falló al actualizar, cuando el primer argumento es 2.

  • Siempre revise el valor retornado por TableUpdate()

    Hay muchas razones por las cuales pueda fallar un TableUpdate() y solo UNA de ellas es el conflicto de actualización, puede pasar que tengas problemas de red, que se caiga tu servidor, falla en la validación a nivel de campo o tabla; poner .T. en el segundo parámetro de TableUpdate() no garantiza que tus datos sean grabados, por lo que siempre deberías revisar si TableUpdate() regresa .T.

  • Ponga atención en el diseño de las bases de datos.

    Revise sus apuntes sobre diseño de base de datos, si estás viendo que tus campos se están repitiendo mucho, deberías reconsiderar el diseño.

  • No “fijes” tus datos a una ruta específica.

    Si estableces las rutas de tus datos hacia una directorio en particular, hacia una unidad de red única, o con una estructura medio rara, obligará a tus usuarios a siempre tenerlo así, nada mas desagradable que eso.

Mal codificado 

USE “F:\VALUACION\DATOS\miTabla”

 
Recomendado 

lcDirectorio = SYS(5)+SYS(2003)
lcPathData = ADBS(lcDirectorio + “\Data”))
SET PATH TO (lcPathData)
USE MiTabla

 
  • Utiliza las reglas de Integridad

    No es muy buena idea dejar que cualquiera (inclusive su diseñador) puede borrar registros “padre” sin asegurarse antes de borrar los registros “hijos”, inclusive se pueden restringir dicha acción, el no usarlos es una facilidad que ofrece Visual FoxPro, el cuál debería ser aprovechada.

 

Descarga

Errores comunes en Microsoft Visual FoxPro

 

Referencias

Artículo publicado en: PortalFox

Autor: Espartaco Palma Martínez

 
error: Contenido protegido