El problemático SET FILTER

El comando SET FILTER era muy útil. Era, tiempo pasado.

Antes de que Visual FoxPro tuviera los comandos SQL, cuando se quería mostrar o procesar solamente algunos registros de una tabla el SET FILTER resultaba de mucha utilidad.

Pero…luego tuvimos SQL y ahora usar SET FILTER es siempre un error. Siempre. Siempre es un error. No hay excepción a esa regla.

Desde luego que si quieres seguir usándolo lo seguirás usando, nadie puede obligarte a que no lo uses. Pero estarás haciendo algo incorrecto.

¿Por qué?

Porque hay una mejor alternativa y esa mejor alternativa es usar el SELECT – SQL como veremos enseguida.

¿Cuáles son los problemas con SET FILTER?

1. Que los registros que no cumplen la condición se vuelven inaccesibles y es imposible saber si una tabla o cursor está «filtrada», o no lo está.
2. Que si usaste alguna variable en tu condición del filtro y el alcance de esa variable no es el adecuado, obtendrás un mensaje de error del VFP.

Listado 1. Un SET FILTER problemático

  DO PROC1
  DO PROC2

RETURN
*
*
PROCEDURE PROC1
LOCAL lnAnoEje
  
  USE "C:\VISUAL FOXPRO\CONTA\ARCHIVOS\DEMO\CUENTAS"
  
  lnAnoEje = 2003
  
  SET FILTER TO CUE_EJERCI = lnAnoEje
  
  BROWSE
  
ENDPROC
*
*
PROCEDURE PROC2
  
  BROWSE
  
ENDPROC
*
*

En el Listado 1. vemos un ejemplo del problema que podemos tener cuando usamos SET FILTER. Si ejecutamos ese programa, el comando BROWSE que se encuentra en PROC1 se mostrará bien, pero el comando BROWSE que se encuentra en PROC2 causará un error:

Captura 1. Mensaje de error obtenido por usar SET FILTER con alcance local

¿Cuál es el problema? Que la variable lnAnoEje tiene un alcance local y por lo tanto solamente se la puede usar en PROC1. Y si en lugar de LOCAL ponemos PRIVATE entonces el problema continuará, obtendremos el mismo mensaje de error. Una solución sería declarar a esa variable como PUBLIC pero si eres un buen programador entonces sabrás que nunca debes usar PUBLIC. Otra solución sería declarar a la variable lnAnoEje como PRIVATE pero antes de ejecutar a PROC1. Sin embargo, en ese caso estarías escribiendo más código y por lo tanto perdiendo más tiempo e incrementando la probabilidad de cometer otro error.

Listado 2. Otro SET FILTER problemático

PRIVATE pnAnoEje
  
  pnAnoEje = 0
  
  DO PROC1
  DO PROC2
  
RETURN
*
*
PROCEDURE PROC1
  
  USE "C:\VISUAL FOXPRO\CONTA\ARCHIVOS\DEMO\CUENTAS"

  pnAnoEje = 2003

  SET FILTER TO CUE_EJERCI = pnAnoEje
  
  BROWSE

ENDPROC
*
*
PROCEDURE PROC2
  
  SELECT CUENTAS
  
  BROWSE
  
ENDPROC
*
*

En el Listado 2. aplicamos una solución y ya el comando BROWSE del PROC2 no nos muestra un mensaje de error, pero…hay otro pero.

¿Cuál es el problema ahora?

Que en PROC2 seleccionamos a nuestra tabla y no vemos que está filtrada. En este caso, el comando BROWSE solamente nos mostrará los registros correspondientes al año 2003 y ninguno más. ¿Y qué pasaría si también quisiéramos ver o procesar los registros de otros años? Pues que no podríamos hacerlo porque dichos registros están totalmente inaccesibles.

Listado 3. La solución es usar el SELECT – SQL

  DO PROC1
  DO PROC2
  
RETURN
*
*
PROCEDURE PROC1
LOCAL lnAnoEje
  
  lnAnoEje = 2003
  
  SELECT * FROM "C:\VISUAL FOXPRO\CONTA\ARCHIVOS\DEMO\CUENTAS" WHERE 1 = 1 INTO CURSOR MISCUENTAS
  
  BROWSE
  
  SELECT * FROM MISCUENTAS WHERE CUE_EJERCI = lnAnoEje INTO CURSOR CUENTAS_2003
  
ENDPROC
*
*
PROCEDURE PROC2
  
  SELECT CUENTAS_2003
  
  BROWSE
  
  SELECT MISCUENTAS
  
  BROWSE
  
ENDPROC
*
*

El programa mostrado en el Listado 3. funciona perfectamente, aunque la variable lnAnoEje fue declarada como LOCAL y además tenemos acceso a ambos cursores. El cursor MISCUENTAS nos muestra todos los registros de la tabla original y el cursor CUENTAS_2003 nos muestra solamente los registros correspondientes al año 2003 de la tabla original.

O sea, que si programamos de la forma mostrada en el Listado 3. jamás tendremos un problema, en cambio si programamos de la forma antigua, como se mostró en el Listado 1. y en el Listado 2. sí podríamos llegar a tener problemas.

Ya es tu decisión elegir.

Conclusión:

Usar el comando SET FILTER solamente se justificaba antes de que el FoxPro incorporara los comandos SQL. Después de eso, usar SET FILTER ya no se justifica porque es proclive a errores. Claro que si quieres continuar usándolo…

Artículos relacionados:

El índice del blog VFPavanzado