Area de trabajo

[Sandy]

Buenos dias!!...

Tengo una duda... veran, cuando uno trabaja con VFP, se que para utilizar las tablas se deben de asignar en que area se va a abrir dicha tabla..
ejemplo: quiero usar mitabla1 en area 0, entonces la sintaxis es asi: select 0; use mitabla1 alias mitabla1, cierto?

si quiero dos tablas en una misma area, se puede?.. seria algo asi la sintaxis:
select 0
use mitabla1 alias mitabla1

select 0
use mitabla2 alias mitabla2 , hacer esto es correcto?, asignar a una misma area dos tablas?.

Espero comentarios!!

[puentemx10]

No Sandy, no se puede abrir 2 tablas en la misma area de trabajo, tal vez estes confundiendo "Area de trabajo" con "Sesion de datos".

Mira, al abrir una tabla, esta se abre en una area de trabajo. ¿En cual?

Si acabas de abrir Fox es en la 1

Si ya estaba abierto, en la ultima area que usaste (si hay una tabla abierta primero la cierra y luego abre esta ultima)

Al hacer SELECT 1 y luego USE {tabla}, estas abriendo la tabla en el area de trabajo numero 1

Al usar SELECT 0 y luego USE {tabla}, estas abriendo la tabla en un area de trabajo desocupada, es decir, que no tiene abierta ninguna tabla

Si haces SELECT 1 y luego USE {tabla} y esta area de trabajo tiene una tabla abierta, esta se cierra y abre la ultima

En resumen, si vas a abrir varias tablas mejor usa la siguiente sintaxis:

USE {tabla_1} ALIAS {tabla_1} IN 0  --> Al poner IN 0 en el comando USE, te evitas tener que escribir SELECT 0 antes del USE

USE {tabla_2} ALIAS {tabla_2} IN 0

USE {tabla_3} ALIAS {tabla_3} IN 0

Y para posicionarte en una tabla o area de trabajo que vayas a usar, no uses SELECT 1, o SELECT 2; mejor usa SELECT tabla_1, es decir, el alias de la tabla.

Saludos...

[Sandy]

Muchas gracias Antonio!.. Agradezco mucho el tiempo que te tomaste para aclarar mis dudas... ya que mencionas la sesion de datos, como es mejor trabajarla, por default o en privada?, entiendo que si es sesion privada el bufferoverride de las tablas tienen que estar en 3 o 5, y en default en 1.. no se si cual sea mejor opcion...

Saludos y gracias!!

El martes, 14 de enero de 2014 09:11:37 UTC-6, Sandy escribió:

[Analyzer]

Hola Sandy,

Antes que nada:

SET EXCLUSIVE OFF

Luego revisar este interesante enlace:

¿Qué ventaja tiene el USE AGAIN SHARED?

https://groups.google.com/forum/#!topic/publicesvfoxpro/hC86L71Rl-I

Reproduzco aquí el comentario de Fernando D. Bozzo:

USE AGAIN SHARED es la única forma de poder abrir la misma tabla al menos 2 veces en una misma sesión de Fox con alias distintos (para eso es el AGAIN), y lo de SHARED es una buena práctica para independizarse del estado del SET EXCLUSIVE

Extra: Otra buena práctica es abrir como solo-lectura una tabla que no vayas a actualizar (USE xxxx NOUPDATE) y obviamente se puede combinar con los otros modificadores SHARED, AGAIN, etc

Un ejemplo práctico:

Imaginate que tenés un sistema donde usás ciertas tablas para hace modificaciones o consultas, y resulta que querés hacer un nuevo método para hacer unaconsulta sobre una tabla que "podría" estar en uso, pero que no lo sabés con seguridad. En ese caso tu método podría ser algo así:

FUNCTION CONSULTA( taDatos, tnCantRegs )
USE MiTabla AGAIN SHARED NOUPDATE ALIAS "__MiAlias" && El doble guión bajo lo uso para aperturas temporales
SELECT * FROM __MiAlias WHERE LaCondicion INTO ARRAY taDatos
tnCantRegs = _TALLY
USE IN (SELECT("__MiAlias"))
RETURN

Pues este es un uso típico y optimizado de una apertura de tabla como solo-lectura para una consulta. El hecho de abrirla como solo-lectura en este caso es muy importante, ya que el Sistema Operativo no tiene que preparar nada extra para trabajar con transacciones, lo que hace que el acceso sea más rápido.

Saludos!

--
Has recibido este mensaje porque estás suscrito al grupo "Aprenda Visual Foxpro" de Grupos de Google.
Visita este grupo en http://groups.google.com/group/aprendavfp.

[Sandy]

Gracias Analizer... si, yo tengo ese codigo
SET EXCLUSIVE OFF


USE datos IN 0

Habia visto el SHARED mas no sabia como o por que lo hacian... leere el link que me mostras!.
Gracias!

El martes, 14 de enero de 2014 09:11:37 UTC-6, Sandy escribió:

[Analyzer]

Cuando hacemos:

USE mitabla IN 0

Si no ponemos un "alias" a la tabla, VFP asume que el nombre de la tabla será su mismo nombre alias.

Al indicar el IN 0 ponemos en uso la tabla en el área de trabajo con el número menor siguiente que esté disponible.

Eso será rollo interno de VFP que es quien se encargará de controlar el número de área mientras nosotros solo hacemos un:

Select mitabla

Y dejamos que VFP controle el asunto de en qué número de área se abrió la tabla seleccionada.

Aquí es donde el concepto de "programación defensiva" entra a a la escena.

http://www.archivum.info/microsoft.public.es.vfoxpro/2008-12/00018/Re-SOS.html

Saludos!

[Analyzer]

Si no se estará usando buffering, recordar esto en ambiente multiusuario:

Como se entiende el "IF Rock()"

https://groups.google.com/forum/#!topic/publicesvfoxpro/SqGtvh8W_io

Saludos!

[Sandy]

Gracias!, por tu apoyo.. y si, ya se que si no le ponemos un alias VFP asume que el alias es el mismo nombre de la tabla.
Gracias por tu aclaracion.

Saludos.

El martes, 14 de enero de 2014 09:11:37 UTC-6, Sandy escribió:

[moris_gonzalez]

yo acostumbro en el load de cada formulario, abrir las tablas que usare en el form, por ejemplo:

CLOSE TABLE ALL

USE tabla1 in 0 ORDER BY 1

USE tabla1 in 0 order by 2 AGAIN && Esto debido a que debo usar esta misma tabla para SEEK, caso contrario no deja trabajar en el form

use tabla2 in 0

use tabla 3 in

.............

Luego, cuando deseo abrir cualquier tabla lo hago asi:

SELE tabla2 && ejemplo

Luego en el DESTROY del form hago esto:

CLOSE TABLE ALL && Libero todas las tablas

RELEASE thisform  && para liberar el form de la memoria  && aca falta liberar las variables que usa el programa

El martes, 14 de enero de 2014 09:11:37 UTC-6, Sandy escribió:

[Sandy]

Gracias Morris!!.. agradecida por el gesto de aclararme sobre el tema!..

El martes, 14 de enero de 2014 09:11:37 UTC-6, Sandy escribió:

[Analyzer]

Pongo por aquí un comentario interesante de Fernando D. Bozzo sobre el tema del USE

Principalmente lo uso así porque sirve para un SCAN o LOCATE o lo que sea que requiera estar ubicado en la tabla, y unUSE <tabla> IN 0 no te garantiza eso, sino que se va a abrir "en otra área" que normalmente no es la actual.

Fijate que algunos hacen USE <tabla> IN 0 y a continuación hacen SELECT <tabla>, lo cuál no es óptimo, porque se está indicando abrir la tabla "en un área nueva" que no me interesa para luego ir y buscar esa área.

Además es una buena práctica, ya que si da la casualidad de que estás parado en el EOF() de una tabla y hacés una búsqueda en otra, puede no encontrarte el valor aunque exista (no recuerdo que comandos pueden fallar estando en EOF ajeno). En cambio, estando en el área de la tabla, si el valor existe lo encuentra siempre, aunque esté en EOF.

Por lo anterior, esto:

select 0
use tabla

es más óptimo que esto:

use tabla in 0
select tabla

Es algo más para tener en cuenta..

Saludos!

[Sandy]

Gracias Analyzer

El martes, 14 de enero de 2014 09:11:37 UTC-6, Sandy escribió:

[Analyzer]

En este enlace el maestro Bozzo explica muy bien lo del USE.

http://fdbozzo.blogspot.com.es/2014/01/como-usar-una-tabla-foxpro-varias-veces.html

Saludos!

--
Has recibido este mensaje porque estás suscrito al grupo "Visual Foxpro Latinoamérica" de Grupos de Google.
Visita este grupo en http://groups.google.com/group/vfplatino.

[jhernancanom]

 ((Este mensaje es para el admor del grupo; no es para Sandra. Quiero aclararle conceptos))

>>> Además es una buena práctica, ya que si da la casualidad de que estás parado en el EOF() de una tabla y hacés una búsqueda en otra, puede no encontrarte el valor aunque exista (no recuerdo que comandos pueden fallar estando en EOF ajeno). En cambio, estando en el área de la tabla, si el valor existe lo encuentra siempre, aunque esté en EOF.

Hacer una búsqueda estando en el EOF() de un DBF no es problema para la búsqueda MIENTRAS EL ALGORITMO TRATE CON LOS DBF-INDEX-CAMPOS ADECUADOS.

En el sgte script te lo demuestro:

close databases

use CLIENTES shared in 0  && order CODIGO 

use FACTURAS shared in 0  && order NUMERO 

select 0

*** lo sgte no se necesita, pero --aún con ésto-- el resto script funciona bien

use OTRODBFCUALQUIERA exclusive noupdate

go bottom

if !eof()

   skip

endif

***

go top in FACTURAS

do while !eof('FACTURAS')

    if seek(FACTURAS.CODIGO, 'CLIENTES', 'CODIGO')

        replace FACTURAS.NOMBRE with CLIENTES.NOMBRE in FACTURAS

    else

        replace FACTURAS.NOMBRE with '--no encontrado--' in FACTURAS

    endif

    skip in FACTURAS

enddo

Como admor debes tener claros tus conceptos para poder dar apoyo a quien lo requiera.

>>> ...  (no recuerdo qué comandos pueden fallar estando en EOF ajeno)...

No sólo hay comandos que fallen, sino todo el algoritmo, toda la lógica del programador MIENTRAS LOS COMANDOS REFERENTES A LA BÚSQUEDA NO SE AJUSTEN A LA BUSQUEDA.

[jhernancanom]

Amigo analista:

Si necesitas ampliar el tema, me cuentas. 

[Analyzer]

==>Como admor debes tener claros tus conceptos para poder dar apoyo a quien lo requiera

Si gracias por la sugerencia y también por la explicación, la idea es seguir aprendiendo.

Sin embargo, lo que está comentando es una cita que hice de un comentario del amigo Fernando D. Bozzo

Quizás el mismo pueda aclarar su propio comentario ya que también es miembro del grupo.

Saludos!

--
Has recibido este mensaje porque estás suscrito al grupo "Visual Foxpro Latinoamérica" de Grupos de Google.
Visita este grupo en http://groups.google.com/group/vfplatino.

[Fernando D. Bozzo]

Buenos días:

Este comentario es de otro foro y respondía a una pregunta, así que puesto así puede quedar fuera de contexto, pero el caso es que hace varios (muchos varios, más o menos de FoxPro 2.6 DOS y creo que VFP 6 :) años había leído sobre este problema del EOF() y me quedé con la idea de que mejor es estar ubicado en el área de la tabla que se quiere reemplazar. Obviamente este no refiere al SQL sino a los comandos y funciones directos.

El tema es que, a raíz de este comentario de jhernancanom estuve buscando a ver si luego de tantos años encontraba alguna referencia sobre aquello que había leido en su momento o si se había solucionado en las últimas versiones de FoxPro, y veo que lo que puse sigue vigente, pero para una situación especial.

En la ayuda del comando REPLACE, bajo REMARKS, hay una nota que dice lo siguiente:

Note 
If the IN clause is omitted, no replacement occurs if the record pointer is at the end of the file in the current work area and you specify a field in another work area.
 
Por lo demás, jhernancanom tiene razón y las búsquedas no son afectadas.

Saludos!

[Hernan Cano]

Hola, Fernando.

Cuando leì el aporte, supuse que era de colega 'analista' y quise corregirlo.

Sinceramente no sabía que era tuyo.

Pero bueno.... así nos aportamos.

Chao.

[Fer]

No pasa nada Hernán, para eso estamos, para ayudarnos y refrescar conocimientos :-)

Un abrazo!

[Analyzer]

==> Note 

If the IN clause is omitted, no replacement occurs if the record pointer is at the end of the file in the current work area and you specify a field in another work area.

Pongo versión en español según la ayuda de VFP8, por si acaso:

"En la ayuda del comando REPLACE, bajo REMARKS, hay una nota que dice lo siguiente:

Nota   Si se omite la cláusula IN, no se producirá ninguna sustitución si el puntero de registro está al final del archivo del área de trabajo actual y se especifica un campo de otra área de trabajo."

Saludos!

--
Has recibido este mensaje porque estás suscrito al grupo "Visual Foxpro Latinoamérica" de Grupos de Google.
Visita este grupo en http://groups.google.com/group/vfplatino.

[jhernancanom]

Cuéntame amigo 'aprendiz de analista':

¿Acaso éso significa que el algoritmo que propuse falla?

El algoritmo es el sgte:

[Analyzer]

==>¿Acaso éso significa que el algoritmo que propuse falla?

No. Nadie dijo eso.. ¿Por qué la pregunta?..

La idea es seguir aprendiendo y las explicaciones amplían nuestras miras..

Saludos!

[Victor Espina]

No es incorrecto, pero si poco recomendable.  No hay nada de malo con el codigo, pero mi recomendacion seria siempre selecciona el area de trabajo antes de hacer cualquier operacion con ella. La otra recomendacion seria evita usar DO WHILE en escenarios donde el SCAN hace el mismo trabajo.  Esto es porque uno de los errores mas comunes que yo cometia (y asi como yo, muchos) era olvidar poner el SKIP en un DO WHILE sobre una tabla, resultando en un ciclo sin fin.  Siguiendo estos dos consejos, tu codigo quedaria asi:

SELECT FACTURAS

GO TOP

SCAN

 REPLACE nombre WITH IIF(SEEK(codigo, 'CLIENTES', 'CODIGO'), CLIENTES.nombre, '--no encontrado--')

ENDSCAN

ahora, en este caso en particular el SCAN tambien estaria de mas pues un simple REPLACE ALL bastaria:

SELECT FACTURAS

GO TOP

REPLACE ALL nombre WITH IIF(SEEK(codigo, 'CLIENTES', 'CODIGO'), CLIENTES.nombre, '--no encontrado--')

Saludos

Victor Espina

go top in FACTURAS

do while !eof('FACTURAS')

    if seek(FACTURAS.CODIGO, 'CLIENTES', 'CODIGO')

        replace FACTURAS.NOMBRE with CLIENTES.NOMBRE in FACTURAS

    else

        replace FACTURAS.NOMBRE with '--no encontrado--' in FACTURAS

    endif

    skip in FACTURAS

enddo

[Analyzer]

El 27 de enero de 2014, 13:41, Victor Espina <vesp...@gmail.com> escribió:
==> pero mi recomendacion seria siempre selecciona el area de trabajo antes de hacer cualquier operacion con ella.

Por ahi le había indicado a sandy antes precisamente algo parecido.

Creo que el concepto se llama "programación defensiva".

http://www.archivum.info/microsoft.public.es.vfoxpro/2008-12/00018/Re-SOS.html

Saludos!

[Victor Espina]

Exactamente.  Hay algunas reglas que he aprendido con el tiempo, algunas a fuerza de equivocarme y otras por recomendacion de otros expertos:

1. Siempre cierra una estructura de control INMEDIATAMENTE despues de abrirla (IF, FOR, DOWHILE, PROCEDURE, FUNCTION).  Encontrar un IF faltante a veces puede ser todo un reto.

2. Siempre declara una variable antes de usarla

3. Documenta a medida que escribes el codigo; no existe tal cosa como "programo ahora y documento despues"

4. Usa algun tipo de notacion para marcar el tipo que tiene una variable y evita almacenar alli valores de otro tipo.

5. Si tienes mas de 2 IF anidados, regresa y repiensa la rutina.  El nivel de complejidad de un codigo crece exponencialmente en funcion de las estructuras de control anidadas que tengas.

6.  Escribe tu codigo de manera ordenada e identada, a medida que lo escribes.  Eso facilitara la lectura del codigo para otro o para ti mismo despues de un tiempo.

7. Siempre espera lo peor del usuario, porque probablemente te quedes corto.

Hay otra, pero justo ahora no las recuerdo. En fin, ojala les sean de utilidad tanto como lo han sido para mi.

Saludos

Victor Espina

[Fernando D. Bozzo]

Excelentes reglas Víctor! Yo también las aprendí a la fuerza :-)

Agrego algunas:

- Haz recolección de basura antes de terminar cada procedimiento (liberación de referencias de objetos, cierre de tablas, etc). Try/catch ayuda mucho en esto.

- Intenta que los procedimientos sean lo más atómicos posibles y que hagan una sola cosa, ya que esto mejora la mantenibilidad y la capacidad de Unit Testing.

- Refactorizar debe ser parte de tu rutina diaria. Una vez acabes un procedimiento, refactorízalo y encuentra oportunidades de mejora y de encapsulación

- Si un procedimiento tiene demasiados comentarios, esto es síntoma de que debería dividirse en más procedimientos.


Saludos!

[Carlos Miguel FARIAS]

y lo más importante documentar, Documentar, DOCUMENTAR, DOCUMENTAAAARRRR!!!!

[Victor Espina]

Excelentes Fernando.  Lo de la recoleccion de basura es algo que aun estoy aprendiendo. En VFP no es tan critico, pero en C# (y sobre todo en dispositivos mobiles) es la diferencia entre algo que sirva y algo totalmente inutil!

Victor Espina

[Analyzer]

Bonitas reglas tomadas de la experiencia!

Gracias por compartirlas!

Saludos!

[Fer]

Lo crítico depende del nivel de complejidad de la aplicación o del método en FoxPro.
Por ejemplo, haciendo que un objeto padre guarde una referencia del hijo y viceversa, y luego intentar dejar que se limpien las referencias solas al liberar un solo de los objetos, después de varias iteraciones causa el error C0000005
Y así como este hay varios casos más, incluso no hacer esta recolección de forma ordenada hasta puede causar comportamientos raros. Hay varias consultas en los foros por estos motivos.

[Victor Espina]

Si, es correcto Fernando.  Tambien es una de las principales causas de formularios que no desaparecen al cerrarse.  De hecho, algo que intento no hacer mientras pueda es almacenar referencias a controles visuales en propiedades de la forma o en otras partes, justamente por este tema.

Mi ultimo "approach" a este tema fue incluir un metodo "collectGarbage"  dentro de todas mis clases base y, dentro de la clase base para Form incluyo codigo que invoca el metodo "collectGarbage" de la forma asi como de todos los objetos contenidos en ella que contengan dicho metodo (y estos, a su vez, hacen lo mismo con sus controles internos, como el caso de los containers, pageframes, etc).

De esa forma en cada control tengo a mano un metodo donde puedo liberar las referencias y otras cosas, con la seguridad que sera invocado en el momento adecuando.

Saludos

Victor Espina

[Victor Espina]

Aqui les dejo una interesante discusion sobre este tema en FoxWikis, con aportes de varios grandes de VFP incluido el propio Steven Black, Doug Hennig y Randy Pearson:

http://fox.wikis.com/wc.dll?Wiki~ManualGarbageCollection

Saludos

Victor Espina

[Fernando D. Bozzo]

Muy buen material Víctor, al igual que varios otros de fox.wikis que leí estos últimos años.

Hay que contextualizar, sin embargo, que toda la disertación sobre la recolección de basura de esa entrada es anterior a VFP 8, y por eso las soluciones sugeridas son conforme a las limitaciones de la versión de Fox que se usaba en ese momento, que estaba entre la 6 y la 7 (siendo la 7 la más nueva).
Recién los últimos 2 posts son del mismo año que se liberó la 8, que incorporaba try/catch, pero no aportaron nada nuevo el hilo, que ya estaba finaliazado.

Creo que parte de lo que comentan allí ya no es necesario, porque el uso de try/catch es una ayuda inigualable para la liberación de basura. De hecho creo que ayudó a simplificarlo muchísimo y a poder tener todo a la vista.

Para el tema de pasar referencias de objeto, si son pocas, yo prefiero usar los parámetros, ya que al ser variables de memoria se limpian automáticamente y sin dejar nada suelto. Por ejemplo, esta es una de las técnicas que usé en FoxBin2Prg para poder reutilizar los métodos de la clase de entrada dentro de las clases intermedias, ya que ambas son de distintos tipos, la de entrada es CUSTOM mientras que las intermedias son SESSION. Esto me permitió usar métodos ajenos de esta forma:

    PROCEDURE escribirArchivoBin
        LPARAMETERS toModulo, toFoxbin2prg
        (código)
        IF toFoxbin2prg.l_Recompile
            toFoxbin2prg.compileFoxProBinary()
        ENDIF
        (más código)
    ENDPROC

Es un tema interesante este, que da para un hilo aparte o un artículo.

Saludos.-

[Victor Espina]

Esta bien! es una especie de recursividad indirecta!!

Victor Espina

[Analyzer]

==>Es un tema interesante este, que da para un hilo aparte o un artículo.

Pues si gustan abrir el tema con un título descriptivo les aseguro que aquí nadie se va a enojar ;-)

Incluso después de escuchar las opiniones del hilo se podría como conclusión elaborar un artículo y subirlo ya sea al blog del maestro Fernando o el del maestro Victor o a ambos o bien enviarlo como contribución a Portalfox.

Recordar que la idea de este grupo es contribuir al aprendizaje, además de proporcionar soluciones. Sientánse libres para abrir hilos para aportes.

Ya me están dando ganas de retomar lo del manual que dejé inconcluso.

Saludos!