Anónimo
Buffer
Trabajo actualmente de esta forma:
se le 1
use maestro
se le 2
Use detalle
Es así como abro mis tabla (tablas libres), y luego en las diferentes rutinas solo invoco se le 1 o sele2 o el se le que necesito.
Me aconsejan que trabaje con buffer, pregunto :
El trabajar con buffer me aligera el proceso, teniendo en cuenta que cada tabla tiene considerable cantidad de registros.?
El buffer es un cursor temporal , que se aloja en c:\temp (segun config.fpw lo tengo asi tmpfiles=c:\temp) ?
Tengo que cambiar a buffer optimista/pesimista y lo se le 1 por se le maestro, se le 2 por se le detalle y así sucesivamente. ¿Habría algún otro cambio?
Tengo 3 formularios ( del tipo abuelo, padre, hijo), es decir un formulario con un grid con documento 1, este grid llama a otro formulario que tiene un grid por cada registro de documento 1, y este ultimo grid llama a otro formulario con un grid con los items de cada registro del grid 2 (formulario 2)., si defino datassesion en 2 en formulario 1 cual es el comportamiento de los grid en los otros 2 formularios reconocerá los select, se cruzaran cuando otros usuarios entren a esta opción, se respeta el datassesion=2 del primer formulario en los otros 2 formularios.?
Ah me olvidaba, la información actualmente se graba directo en cada tabla de cada grid en los tres formularios, como aplicaría el tableupdate en este caso, ¿o es que movimiendo el cursor del teclado en cada columna o file del grid estos se actualizan automáticamente o en cada columna tendría que hacer tableupdate() para que se grabe la información en la tabla?
Gracias y disculpa por tantas pregunta (y por mi ignorancia)
se le 1
use maestro
se le 2
Use detalle
Es así como abro mis tabla (tablas libres), y luego en las diferentes rutinas solo invoco se le 1 o sele2 o el se le que necesito.
Me aconsejan que trabaje con buffer, pregunto :
El trabajar con buffer me aligera el proceso, teniendo en cuenta que cada tabla tiene considerable cantidad de registros.?
El buffer es un cursor temporal , que se aloja en c:\temp (segun config.fpw lo tengo asi tmpfiles=c:\temp) ?
Tengo que cambiar a buffer optimista/pesimista y lo se le 1 por se le maestro, se le 2 por se le detalle y así sucesivamente. ¿Habría algún otro cambio?
Tengo 3 formularios ( del tipo abuelo, padre, hijo), es decir un formulario con un grid con documento 1, este grid llama a otro formulario que tiene un grid por cada registro de documento 1, y este ultimo grid llama a otro formulario con un grid con los items de cada registro del grid 2 (formulario 2)., si defino datassesion en 2 en formulario 1 cual es el comportamiento de los grid en los otros 2 formularios reconocerá los select, se cruzaran cuando otros usuarios entren a esta opción, se respeta el datassesion=2 del primer formulario en los otros 2 formularios.?
Ah me olvidaba, la información actualmente se graba directo en cada tabla de cada grid en los tres formularios, como aplicaría el tableupdate en este caso, ¿o es que movimiendo el cursor del teclado en cada columna o file del grid estos se actualizan automáticamente o en cada columna tendría que hacer tableupdate() para que se grabe la información en la tabla?
Gracias y disculpa por tantas pregunta (y por mi ignorancia)
2 respuestas
Respuesta de emmacape
1
1.. Trabajar con buffer por supuesto que aligera el proceso porque dejas los datos en memoria y los jalas solo cuando los necesites.. por otro lado yo uso cursores que trabjan en una forma impresionante y que no estas usando la tabla de esta manera evitas saturar la base de datos...
2. A si es en realidad es un cursor actualizable basado en la tabla original. Todos los cambios se han hecho sobre este cursor y sólo se escriben en la tabla cuando se utiliza el comando "update" adecuado.
3.
Estrategias de buffer
La estrategia de buffer determina cuándo y cómo se almacenan en la tabla los cambios que se encuentran en el buffer. Existen tres opciones:
* No se emplea buffer: Esta vía es solamente una opción para las versiones anteriores a Visual Foxpro versión 3.0 y es además, el comportamiento predeterminado actualmente para las tablas de Visual FoxPro. Cualquier cambio hecho en una tabla va directamente e inmediatamente a la tabla original. No hay posibilidad de "deshacer" sin que se haya programado explícitamente - utilizando Scatter y Gather, por ejemplo. Se establece al asignar "1" como parámetro a CursorSetProp()
* Buffer de filas: Los cambios no se han enviado a la tabla original a menos que ocurran una de estas dos cosas. O hay una llamada explícita a la función TableUpdate(), o el puntero del registro se mueve dentro de la tabla original. Vea que CUALQUIER movimiento del puntero del registro, aunque sea iniciado por una tabla que esté en buffer de filas, siempre causa un TableUpdate() "implícito". Establezca 2 ó 3 como parámetro para CursorSetProp().
* Buffer de tabla: Los cambios nunca se envían automáticamente a la tabla original, a menos que exista una llamada a un comando TableUpdate() o TableRevert() siempre debe afectar los cambios que estén guardados en el buffer. Intentar cerrar una tabla con buffer mientras tiene cambios no cometidos provoca que Visual FoxPro genere un error en la versión 3.0; pero este comportamiento cambió en versiones anteriores por tanto, los cambios pendientes simplemente se pierden. (No hay error; ni advertencia de que los cambios se van a perder). Se establece asignando 4 ó 5 como parámetro para CursorSetProp().
Hasta este punto se está preguntando, por qué hay DOS parámetros posibles para cada una de las estrategias que implementan buffer. La respuesta es, como se indica en la introducción, debido a que hay dos estrategias de bloqueo.
Estrategias de bloqueo
Visual FoxPro necesita bloquear el registro físico en la tabla mientras se realizan los cambios en su contenido y existen dos vías con las que se puede establecer el bloqueo automático (opuesto al uso explícito de las funciones RLock()/FLock())
* Bloqueo pesimista: El registro se bloquea en cuanto un usuario comienza a hacer cambios (El bloqueo en realidad ocurre en cuanto se oprime cualquier tecla válida). Esto evita que cualquier otro usuario pueda hacer o guardar cambios sobre este registro hasta tanto el usuario actual haya completado sus cambios y liberado el registro tanto guardando o revirtiendo los cambios.
* Bloqueo optimista: Un intento de bloqueo del registro se hace solamente cuando los cambios se comienzan a enviar a la tabla. Esto significa que incluso mientras un usuario hace cambios en el dato, el registro permanece disponible a otros usuarios, los que también podrían, y posiblemente guardarán, cambios en el mismo registro mientras el primer usuario están aun trabajando en el.
Modos de buffer
El modo de buffer para una tabla es, por tanto, la combinación específica de las estrategias de Buffer y Bloqueo que se aplican. Existe un total de 5 modos de buffer para una tabla como se ilustra en la Tabla 1.
Tabla 1. Modos de Buffer en Visual FoxPro
Modo Bloqueo Buffer Comentarios
1 Pesimista Ninguno Única opción para FP2. Por, predeterminado para tablas VFP
2 Pesimista Fila El bloqueo se establece por el evento KeyPress. El movimiento del puntero de registro obliga a Guardar
3 Optimista Fila El bloqueo se establece por TableUpdate(). El movimiento del puntero de registro obliga a Guardar
4 Pesimista Tabla El bloqueo se establece por el evento KeyPress. Guardar se debe iniciar explícitamente
5 Optimista Tabla El bloqueo se establece por el evento TableUpdate(). Guardar se debe iniciar explícitamente
Al trabajar con Visual FoxPro, debemos ser cuidadosos al distinguir entre estrategias individuales, que se especifican directamente para Buffer y Bloqueo, y el modo buffer que resulta de la combinación de ellos. Desafortunadamente, como hemos visto, Visual FoxPro es de por sí, menos cuidadoso con esta distinción.
¿Qué significa todo esto cuando creamos formularios enlazados a datos?
He aquí donde las cosas comienzan a ponerse un poco más complejas (y no es solamente por la nomenclatura). Consideremos una situación normal donde las tablas se agregan al formulario por el entorno de datos nativo. El formulario tiene una propiedad llamada "Buffermode" que tiene tres valores posibles:
* 0 Ninguno (predeterminado)
* 1 Pesimista
* 2 Optimista
Vea que esto se refiere en realidad a las opciones para la estrategia de bloqueo y no tiene nada que ver con el buffer ¡ Para nada ! El hecho por el cual el formulario determina la estrategia buffer es por sus tablas todas por si mismo, basadas en su utilización. Si un formulario utiliza dos tablas que tienen una relación de uno a muchos, muestran el lado "muchos" de la relación de diferentes formas.
Si la tabla "muchos" se utiliza como origen de datos para el control grid, para el formulario, se abre con buffer de tabla. Sin embargo, si la tabla "muchos" se emplea para enlazar con controles que solamente muestran una fila de la tabla cada vez entonces, el buffer para la tabla va a ser lo mismo que para "una" tabla para toda de configuración de la propiedad Buffermode del formulario.
Si crea un pequeño formulario de prueba y ejecuta todas sus opciones para la propiedad Buffermode de un formulario, puede ver que incluso con la propiedad BufferMode establecida en 0-(Ninguna) el cursor creado por Visual FoxPro está aun abierto en modo buffer de fila cuando las tablas se abren desde el entorno de datos del formulario. Es como si para el formulario "No buffer" y "Buffer de filas" fuera lo mismo.
Sin embargo, este NO es el caso si las tablas se abren directamente con el comando USE. Si las tablas se abren explícitamente en el método Load(), entonces la propiedad Buffermode no tiene impacto en lo absoluto, y las tablas se abren en dependencia de los parámetros apropiados en la Sesión de datos. Para formularios que corren en la sesión predeterminada de datos (DataSession = 1) se utilizan los parámetros especificados en la ventana Opciones. Vea que en la ventana Opciones, las opciones, en realidad establecen la configuración del modo de buffer. Tiene las 5 opciones que se corresponden con lo 5 modos definidos antes, en la Tabla 1, y los que utilizan los mismos identificadores que la función CursorSetProp(). Si el formulario se ejecuta en sesión privada de datos, entonces, las tablas abiertas con el comando USE se configuran en dependencia de la configuración establecida para esa sesión de datos y, de forma predeterminada, no serán alojadas en buffer.
¿Aun confundido?
Lo más que puedo decir es que la situación es realmente como sigue:
* Para las tablas abiertas por el entorno de datos del formulario, no importa si el formulario tiene Datassesion con valor Default o Private. Las tablas siempre tienen almacenamiento en buffer, al menos en modo Optimista de filas.
* La propiedad BufferMode del formulario en realidad determina la estrategia de bloqueo, no el modo de buffer; pero solo para tablas que han sido abiertas en el entorno de datos del formulario.
* En la sesión de datos actual, las tablas que han sido abiertas explícitamente tienen ambas estrategias: buffer y bloqueo establecidas en dependencia de la ventana Opciones.
* En la sesión Privada de datos, las tablas que han sido abiertas explícitamente tienen sus estrategias de buffer y bloqueo establecidas de acuerdo a los parámetros que se han aplicado para esta sesión (Predeterminado = "No Buffering")
* Estos resultados se pueden verificar estableciendo varias opciones en un formulario sencillo y mostrando el resultado que se obtiene por CURSORGETPROP("BUFFERING")
Entonces, ¿cómo debemos establecer el buffer para un formulario?
La respuesta corta, como siempre, es "depende". Si utiliza el entorno de datos del formulario para abrir las tablas entonces, puede normalmente dejar la opción al Visual FoxPro. En caso contrario puede simplemente emplear la función CursorSetProp() en su código para configurar cada tabla como sea necesario. De cualquier manera necesita ser consciente de las consecuencias para que pueda programar sus actualizaciones rápidamente.
Utilizar BufferModeOverride
La clase dataenvironment posee una propiedad para cada tabla (o, mejor dicho, "cursor") llamado "BufferModeOverride". Esta propiedad va a fijar el modo del buffer para esa tabla (y sólo esa tabla) a una de las estas seis opciones - si, es correcto, SEIS opciones, no cinco - veamos:
* 0 Ninguno
* 1 (Predeterminado) Utilizar la configuración del formulario.
* 2 Búffer pesimista de fila
* 3 Buffer optimista de fila
* 4 Buffer pesimista de tabla
* 5 Buffer optimista de tabla
Existen dos puntos sobre los que hay que prestar atención. Primero, Vea que mientras los números del 2 al 5 se corresponden con los parámetros de CursorSetProp() y son aquellos mismos que están disponibles desde el diálogo Opciones, el valor requerido para la configuración "ninguno" ahora es 0 en lugar de 1. He aquí otra inconsistencia en la configuración del buffer. Segundo, vea que el valor predeterminado para esta propiedad es "1 - Utiliza la configuración de formularios". Cuando se refiere a configuración de formularios, se refiere, por supuesto a la propiedad "BufferMode", la que como ya hemos visto en realidad se encarga de definir la estrategia de bloqueo a aplicar. No existe configuración del formulario para controlar buffer !.
Habiendo dicho esto, la configuración de la propiedad BufferModeOverride va a asegurar que la tabla se abre utilizando el modo buffer que usted ha especificado. Al menos esta propiedad ha sido nombrada correctamente, sobreescribe todo lo demás y fuerza la tabla a un modo especial de buffer en todas las situaciones.
Utilizar CursorSetProp()
Independientemente de cómo fue abierta la tabla, siempre puede utilizar la función CursorSetProp() para cambiar el modo buffer de una tabla. Sin embargo, si está utilizando el entorno de datos del formulario para abrir sus tablas, entonces, tiene dos opciones en dependencia de si su formulario utiliza sesión privada de datos o sesión actual de datos. En el primer caso, puede establecer simplemente el modo requerido en la ventana Opciones y olvidarse de ello. Todas las tablas se van a abrir siempre con esa configuración y siempre sabrá en qué estado se encuentra. Si utiliza una sesión privada de datos entonces, necesita hacer dos cosas. Primero, necesita asegurarse de que el entorno de datos está configurado para soportar buffer. Algunos parámetros de entorno se limitan a la sesión de datos actual y puede que necesite cambiar el comportamiento predeterminado o alguno, o todos los siguientes (vea el tema SET DATASESSION en el archivo ayuda para una lista completa de parámetros afectados):
* SET MULTILOCKS - Debe ser ON para permitir buffer, predeterminado OFF
* SET DELETED - Predeterminado OFF
* SET DATABASE - "No database" es el predeterminado en una sesión Privada
* SET EXCLUSIVE - El predeterminado es OFF para una sesión Privada
* SET LOCK - Predeterminado OFF
* SET COLLATE - Predeterminado es "MACHINE"
* SET EXACT - Predeterminado es OFF
Lo segundo que necesita es especificar explícitamente el modo buffer de cada tabla utilizada en la función CursorSetProp() con el parámetro apropiado porque la configuración en la ventana Opciones no se puede aplicar a la sesión privada de datos.
Entonces, ¿qué modo de buffer debo utilizar en mis formulario?
Para nosotros la respuesta es sencilla. Siempre debe utilizar estrategia de buffer de tabla con bloqueo optimista (es decir modo de buffer 5). La razón es simplemente que, con la excepción de creación de un índice, no hay nada que pueda hacer en otro modo que no pueda hacer en este modo. Mientras el buffer de filas puede ser utilizado en desarrollo, no creemos que tienen cabida en una aplicación en funcionamiento. La razón es simplemente que existe muchas formas en las que puede ser desencadenada la función TableUpdate() implícito (causado por el movimiento del puntero de registro) y no todos los que están por debajo de nuestro control directo. Por ejemplo, la función KeyMatch() está definida en el archivo Ayuda, como;
Busca una clave de índice en una etiqueta o un archivo de índice.
Parece suficientemente inofensivo - seguramente buscar un archivo índice no puede causar problemas. Pero una nota (en la sección Observaciones justo al final del tema) indica que:
KEYMATCH( ) devuelve el puntero de registro al registro donde estaba originalmente antes de ejecutar KEYMATCH( ).
Aquí se bloquea! Seguramente "devuelve el puntero de registro" implica que mueve el puntero del cursor - lo que en efecto - hace. La consecuencia es que si está utilizando el buffer de filas y quiere verificar por clave duplicados utilizando keymatch(), puede realizar inmediatamente cualquier cambio pendiente. (Por supuesto, en la versión 6 o después pueden siempre utilizar en su lugar IndexSeek(). Sin embargo, el mismo problema surge cuando muchos de los comandos y funciones que operan sobre una tabla - especialmente el más viejo introducido en FoxPro antes los días de buffer (e.g. CALCULATE, SUM y AVERAGE).
Aun más importante, el hecho de que configure una tabla para buffer de tabla no lo previene de que la tabla como si en realidad hubiera buffer de filas. Ambas funciones TableUpdate() y TableRevert(). Esto puede significar que tiene que escribir un poco más de código; pero puede evitar muchos problemas.
Cambiar el modo de buffer de la tabla
Hemos dicho, al inicio de la última sesión, que puede utilizar siempre CursorSetProp() para establecer o cambiar el modo de buffer de una tabla. Esto es cierto; pero si la tabla ya ha tenido asignado un modo buffer, puede no ser tan sencillo porque al cambiar el estado de buffer forzaría a Visual FoxPro a verificar el estado de cualquier buffer existente.
Si la tabla tiene buffer de filas, y tiene cambios no confirmados, Visual FoxPro los envía y permite cambiar el modo. Si el destino tiene buffer de tablas, y trata de cambiar su modo de buffer mientras existen cambios no confirmados, Visual FoxPro se queja y manda el error 1545 ("El búfer de tablas para el alias "nombre" contiene cambios no confirmados"). Esto es un problema porque no puede indexar una tabla, o hacerla libre una tabla o cursor transactable, los que mientras la tabla tiene buffer, por tanto es la única vía de hacer estas cosas, temporalmente, a buffer de filas. Por supuesto, la solución es siempre suficiente - asegúrese sólo de que no hay cambios pendientes antes de que intente cambiar el modo de buffer.
4.. 00
Para asegurarse de que todos los usuarios de un entorno compartido disponen de un duplicado exacto y seguro del entorno, y que múltiples instancias de un formulario pueden funcionar independientemente, Visual FoxPro proporciona sesiones de datos.
Una sesión de datos es una representación del entorno de trabajo dinámico actual. Podría considerar la sesión de datos como un entorno de datos en miniatura dentro de una sesión de Visual FoxPro abierta en un equipo. Cada sesión de datos contiene:
Una copia de los elementos en el entorno de datos del formulario
Cursores que representan las tablas abiertas, sus índices y relaciones.
El concepto de una sesión de datos se entiende fácilmente cuando se considera lo que ocurre al abrir el mismo formulario simultáneamente en dos estaciones de trabajo diferentes en una aplicación multiusuario. En este caso, cada estación de trabajo ejecuta una sesión de Visual FoxPro diferente y, por tanto, tiene su propio conjunto de áreas de trabajo: cursores que representan las tablas base abiertas, los índices y las relaciones.
Sin embargo, si abre en un solo equipo múltiples instancias del mismo formulario en un solo proyecto, dentro de la misma sesión de Visual FoxPro, los formularios comparten la sesión de datos predeterminada, lo que representa un único entorno de trabajo dinámico. Cada instancia del formulario abierto en la misma sesión de Visual FoxPro usa el mismo conjunto de áreas de trabajo y las acciones en una única instancia de un formulario que mueven el puntero de registro en un área de trabajo afectan automáticamente a otras instancias del mismo formulario.
Usar sesiones privadas de datos
Si desea tener más control sobre múltiples instancias de un formulario, puede implementar sesiones privadas de datos. Cuando el formulario utiliza sesiones privadas de datos, Visual FoxPro crea una nueva sesión de datos para cada instancia del control Form, FormSet o Toolbar que crea la aplicación. Cada sesión privada de datos contiene:
Una copia diferente de cada tabla, índice y relación del entorno de datos del formulario.
Un número ilimitado de áreas de trabajo.
Punteros de registro para la copia de cada tabla, independientes de las tablas base del formulario.
El número de sesiones de datos disponibles está limitado sólo por la memoria y el espacio en disco disponible en el sistema.
Las sesiones privadas de datos se implementan al establecer la propiedad DataSession para el formulario. La propiedad DataSession tiene dos configuraciones:
¿1? Sesión predeterminada de datos (la configuración predeterminada).
¿2? Sesión privada de datos.
El valor predeterminado de la propiedad DataSession es 1.
Para activar las sesiones privadas de datos
Elija una de las opciones siguientes:
En el Diseñador de formularios, ¿establezca la propiedad DataSession del formulario como 2? Sesión privada de datos.
? ¿O bien?
En el código, establezca la propiedad DataSession a 2.
Por ejemplo, escriba:
frmFormName.DataSession = 2
Nota Sólo puede establecer la propiedad DataSession durante el diseño y, en tiempo de ejecución, esta propiedad es de sólo lectura.
Cuando un formulario utiliza sesiones privadas de datos, cada instancia de un formulario abierta en un solo equipo en una única sesión de Visual FoxPro usa su propio entorno de datos. El uso de sesiones privadas de datos es similar a la ejecución simultánea del mismo formulario desde diferentes estaciones de trabajo.
Múltiples sesiones de datos equivalentes
Identificar sesiones de datos
Cada sesión privada de datos se identifica por separado. Puede ver el contenido de cada sesión de datos en la ventana Sesión de datos. También puede cambiar la descripción de la sesión de datos mediante comandos en el código del evento Load.
Puede ver el número de identificación de cada sesión de datos mediante la propiedad de tiempo de ejecución DataSessionID. El ejemplo siguiente muestra la propiedad DataSessionID de un formulario denominado frmMiFormulario:
DO FORM frmMiFormulario
? FrmMiFormulario. DataSessionID
Si activa el formulario mediante la cláusula NAME, puede usar el nombre del formulario para tener acceso a la propiedad DataSessionID, como en el código siguiente:
DO FORM MiFormulario NAME one
? One. DataSessionID
La propiedad DataSessionID sirve para identificar una sesión de datos determinada. Evite cambiar la propiedad DataSessionID de una instancia de un formulario porque los controles dependientes de datos pierden sus orígenes de datos cuando se modifica esta propiedad.
Actualizar datos con múltiples instancias de un formulario
Mientras que las sesiones privadas de datos generan áreas de trabajo diferentes que contienen copias independientes de las tablas abiertas, índices y relaciones de un formulario, cada copia del formulario hace referencia a los mismos archivos de tablas base y de índices base subyacentes. Cuando un usuario actualiza un registro en una instancia de un formulario, se actualiza la tabla base a la que hace referencia el formulario. Los cambios realizados en otra instancia del formulario pueden verse al desplazarse por el registro modificado.
Los bloqueos realizados en registros o tablas en una sesión privada de datos son respetados por otras sesiones privadas de datos. Por ejemplo, si el usuario de la sesión de datos 1 pone un bloqueo en un registro, el usuario de la sesión de datos 2 no puede bloquear el registro. Si el usuario de la sesión 1 abre una tabla de forma exclusiva, el usuario de la sesión de datos 2 no puede abrir la tabla. Respetando los bloqueos realizados por otras sesiones de datos, Visual FoxPro protege la integridad de las actualizaciones en las tablas base subyacentes.
Personalizar el entorno de una sesión de datos
Debido a que las sesiones de datos controlan el alcance de determinados comandos SET, puede usar sesiones privadas de datos para establecer configuraciones personalizadas de comandos SET dentro de una sola sesión de Visual FoxPro.
Por ejemplo, el comando SET EXACT, que controla las reglas utilizadas al comparar cadenas de caracteres de diferentes longitudes, pertenece al ámbito de la sesión de datos actual. La configuración predeterminada de SET EXACT es Off, lo que especifica que, para ser equivalentes, las expresiones deben coincidir, carácter a carácter, hasta que se llega al final de las expresiones en el lado derecho. Tal vez desee activar búsquedas "borrosas" o equivalentes; para ello, establezca SET EXACT como OFF para la sesión de datos actual. Sin embargo, la aplicación podría contener un formulario determinado que requiriera coincidencias exactas. Podría establecer la propiedad DataSession como 2 para el formulario que requiere coincidencias exactas, para activar las sesiones privadas de datos y después establecer SET EXACT a ON para ese formulario. Si ejecuta un comando SET sólo para el formulario que utiliza sesiones privadas de datos, se mantiene intacta la configuración global de la sesión de Visual FoxPro a la vez que permite la configuración personalizada para un formulario determinado.
Ignorar la asignación automática de sesión de datos
Cuando las sesiones privadas de datos para un formulario están en uso, los cambios realizados en los datos de un formulario no se representan automáticamente en otras instancias del mismo formulario. Si desea que todas las instancias de un formulario tengan acceso a los mismos datos y reflejen automáticamente los cambios realizados en datos comunes, puede ignorar la asignación automática de sesión de datos.
Para ignorar la asignación automática de sesión de datos
Utilice uno de estos comandos:
SET DATASESSION TO 1
?O bien?
SET DATASESSION TO
Ambos comandos permiten controlar la sesión de datos predeterminada mediante la ventana Comandos y el Administrador de proyectos.
5.. esto es según si estas trabajando con buffer=5.. tendrás que poner
se le tabla
=tableupdate(.t.)
para guardar los cambio
'o
sele tabla
=tablerevert(.t.)
Para quitar los cambios..
Amigo espero no haberte saturado de información, puedes leer la mitad probar y después la otra mitad, y espero haberte ayudado... cualquier duda
[email protected] emmanuel carrillo ponce
2. A si es en realidad es un cursor actualizable basado en la tabla original. Todos los cambios se han hecho sobre este cursor y sólo se escriben en la tabla cuando se utiliza el comando "update" adecuado.
3.
Estrategias de buffer
La estrategia de buffer determina cuándo y cómo se almacenan en la tabla los cambios que se encuentran en el buffer. Existen tres opciones:
* No se emplea buffer: Esta vía es solamente una opción para las versiones anteriores a Visual Foxpro versión 3.0 y es además, el comportamiento predeterminado actualmente para las tablas de Visual FoxPro. Cualquier cambio hecho en una tabla va directamente e inmediatamente a la tabla original. No hay posibilidad de "deshacer" sin que se haya programado explícitamente - utilizando Scatter y Gather, por ejemplo. Se establece al asignar "1" como parámetro a CursorSetProp()
* Buffer de filas: Los cambios no se han enviado a la tabla original a menos que ocurran una de estas dos cosas. O hay una llamada explícita a la función TableUpdate(), o el puntero del registro se mueve dentro de la tabla original. Vea que CUALQUIER movimiento del puntero del registro, aunque sea iniciado por una tabla que esté en buffer de filas, siempre causa un TableUpdate() "implícito". Establezca 2 ó 3 como parámetro para CursorSetProp().
* Buffer de tabla: Los cambios nunca se envían automáticamente a la tabla original, a menos que exista una llamada a un comando TableUpdate() o TableRevert() siempre debe afectar los cambios que estén guardados en el buffer. Intentar cerrar una tabla con buffer mientras tiene cambios no cometidos provoca que Visual FoxPro genere un error en la versión 3.0; pero este comportamiento cambió en versiones anteriores por tanto, los cambios pendientes simplemente se pierden. (No hay error; ni advertencia de que los cambios se van a perder). Se establece asignando 4 ó 5 como parámetro para CursorSetProp().
Hasta este punto se está preguntando, por qué hay DOS parámetros posibles para cada una de las estrategias que implementan buffer. La respuesta es, como se indica en la introducción, debido a que hay dos estrategias de bloqueo.
Estrategias de bloqueo
Visual FoxPro necesita bloquear el registro físico en la tabla mientras se realizan los cambios en su contenido y existen dos vías con las que se puede establecer el bloqueo automático (opuesto al uso explícito de las funciones RLock()/FLock())
* Bloqueo pesimista: El registro se bloquea en cuanto un usuario comienza a hacer cambios (El bloqueo en realidad ocurre en cuanto se oprime cualquier tecla válida). Esto evita que cualquier otro usuario pueda hacer o guardar cambios sobre este registro hasta tanto el usuario actual haya completado sus cambios y liberado el registro tanto guardando o revirtiendo los cambios.
* Bloqueo optimista: Un intento de bloqueo del registro se hace solamente cuando los cambios se comienzan a enviar a la tabla. Esto significa que incluso mientras un usuario hace cambios en el dato, el registro permanece disponible a otros usuarios, los que también podrían, y posiblemente guardarán, cambios en el mismo registro mientras el primer usuario están aun trabajando en el.
Modos de buffer
El modo de buffer para una tabla es, por tanto, la combinación específica de las estrategias de Buffer y Bloqueo que se aplican. Existe un total de 5 modos de buffer para una tabla como se ilustra en la Tabla 1.
Tabla 1. Modos de Buffer en Visual FoxPro
Modo Bloqueo Buffer Comentarios
1 Pesimista Ninguno Única opción para FP2. Por, predeterminado para tablas VFP
2 Pesimista Fila El bloqueo se establece por el evento KeyPress. El movimiento del puntero de registro obliga a Guardar
3 Optimista Fila El bloqueo se establece por TableUpdate(). El movimiento del puntero de registro obliga a Guardar
4 Pesimista Tabla El bloqueo se establece por el evento KeyPress. Guardar se debe iniciar explícitamente
5 Optimista Tabla El bloqueo se establece por el evento TableUpdate(). Guardar se debe iniciar explícitamente
Al trabajar con Visual FoxPro, debemos ser cuidadosos al distinguir entre estrategias individuales, que se especifican directamente para Buffer y Bloqueo, y el modo buffer que resulta de la combinación de ellos. Desafortunadamente, como hemos visto, Visual FoxPro es de por sí, menos cuidadoso con esta distinción.
¿Qué significa todo esto cuando creamos formularios enlazados a datos?
He aquí donde las cosas comienzan a ponerse un poco más complejas (y no es solamente por la nomenclatura). Consideremos una situación normal donde las tablas se agregan al formulario por el entorno de datos nativo. El formulario tiene una propiedad llamada "Buffermode" que tiene tres valores posibles:
* 0 Ninguno (predeterminado)
* 1 Pesimista
* 2 Optimista
Vea que esto se refiere en realidad a las opciones para la estrategia de bloqueo y no tiene nada que ver con el buffer ¡ Para nada ! El hecho por el cual el formulario determina la estrategia buffer es por sus tablas todas por si mismo, basadas en su utilización. Si un formulario utiliza dos tablas que tienen una relación de uno a muchos, muestran el lado "muchos" de la relación de diferentes formas.
Si la tabla "muchos" se utiliza como origen de datos para el control grid, para el formulario, se abre con buffer de tabla. Sin embargo, si la tabla "muchos" se emplea para enlazar con controles que solamente muestran una fila de la tabla cada vez entonces, el buffer para la tabla va a ser lo mismo que para "una" tabla para toda de configuración de la propiedad Buffermode del formulario.
Si crea un pequeño formulario de prueba y ejecuta todas sus opciones para la propiedad Buffermode de un formulario, puede ver que incluso con la propiedad BufferMode establecida en 0-(Ninguna) el cursor creado por Visual FoxPro está aun abierto en modo buffer de fila cuando las tablas se abren desde el entorno de datos del formulario. Es como si para el formulario "No buffer" y "Buffer de filas" fuera lo mismo.
Sin embargo, este NO es el caso si las tablas se abren directamente con el comando USE. Si las tablas se abren explícitamente en el método Load(), entonces la propiedad Buffermode no tiene impacto en lo absoluto, y las tablas se abren en dependencia de los parámetros apropiados en la Sesión de datos. Para formularios que corren en la sesión predeterminada de datos (DataSession = 1) se utilizan los parámetros especificados en la ventana Opciones. Vea que en la ventana Opciones, las opciones, en realidad establecen la configuración del modo de buffer. Tiene las 5 opciones que se corresponden con lo 5 modos definidos antes, en la Tabla 1, y los que utilizan los mismos identificadores que la función CursorSetProp(). Si el formulario se ejecuta en sesión privada de datos, entonces, las tablas abiertas con el comando USE se configuran en dependencia de la configuración establecida para esa sesión de datos y, de forma predeterminada, no serán alojadas en buffer.
¿Aun confundido?
Lo más que puedo decir es que la situación es realmente como sigue:
* Para las tablas abiertas por el entorno de datos del formulario, no importa si el formulario tiene Datassesion con valor Default o Private. Las tablas siempre tienen almacenamiento en buffer, al menos en modo Optimista de filas.
* La propiedad BufferMode del formulario en realidad determina la estrategia de bloqueo, no el modo de buffer; pero solo para tablas que han sido abiertas en el entorno de datos del formulario.
* En la sesión de datos actual, las tablas que han sido abiertas explícitamente tienen ambas estrategias: buffer y bloqueo establecidas en dependencia de la ventana Opciones.
* En la sesión Privada de datos, las tablas que han sido abiertas explícitamente tienen sus estrategias de buffer y bloqueo establecidas de acuerdo a los parámetros que se han aplicado para esta sesión (Predeterminado = "No Buffering")
* Estos resultados se pueden verificar estableciendo varias opciones en un formulario sencillo y mostrando el resultado que se obtiene por CURSORGETPROP("BUFFERING")
Entonces, ¿cómo debemos establecer el buffer para un formulario?
La respuesta corta, como siempre, es "depende". Si utiliza el entorno de datos del formulario para abrir las tablas entonces, puede normalmente dejar la opción al Visual FoxPro. En caso contrario puede simplemente emplear la función CursorSetProp() en su código para configurar cada tabla como sea necesario. De cualquier manera necesita ser consciente de las consecuencias para que pueda programar sus actualizaciones rápidamente.
Utilizar BufferModeOverride
La clase dataenvironment posee una propiedad para cada tabla (o, mejor dicho, "cursor") llamado "BufferModeOverride". Esta propiedad va a fijar el modo del buffer para esa tabla (y sólo esa tabla) a una de las estas seis opciones - si, es correcto, SEIS opciones, no cinco - veamos:
* 0 Ninguno
* 1 (Predeterminado) Utilizar la configuración del formulario.
* 2 Búffer pesimista de fila
* 3 Buffer optimista de fila
* 4 Buffer pesimista de tabla
* 5 Buffer optimista de tabla
Existen dos puntos sobre los que hay que prestar atención. Primero, Vea que mientras los números del 2 al 5 se corresponden con los parámetros de CursorSetProp() y son aquellos mismos que están disponibles desde el diálogo Opciones, el valor requerido para la configuración "ninguno" ahora es 0 en lugar de 1. He aquí otra inconsistencia en la configuración del buffer. Segundo, vea que el valor predeterminado para esta propiedad es "1 - Utiliza la configuración de formularios". Cuando se refiere a configuración de formularios, se refiere, por supuesto a la propiedad "BufferMode", la que como ya hemos visto en realidad se encarga de definir la estrategia de bloqueo a aplicar. No existe configuración del formulario para controlar buffer !.
Habiendo dicho esto, la configuración de la propiedad BufferModeOverride va a asegurar que la tabla se abre utilizando el modo buffer que usted ha especificado. Al menos esta propiedad ha sido nombrada correctamente, sobreescribe todo lo demás y fuerza la tabla a un modo especial de buffer en todas las situaciones.
Utilizar CursorSetProp()
Independientemente de cómo fue abierta la tabla, siempre puede utilizar la función CursorSetProp() para cambiar el modo buffer de una tabla. Sin embargo, si está utilizando el entorno de datos del formulario para abrir sus tablas, entonces, tiene dos opciones en dependencia de si su formulario utiliza sesión privada de datos o sesión actual de datos. En el primer caso, puede establecer simplemente el modo requerido en la ventana Opciones y olvidarse de ello. Todas las tablas se van a abrir siempre con esa configuración y siempre sabrá en qué estado se encuentra. Si utiliza una sesión privada de datos entonces, necesita hacer dos cosas. Primero, necesita asegurarse de que el entorno de datos está configurado para soportar buffer. Algunos parámetros de entorno se limitan a la sesión de datos actual y puede que necesite cambiar el comportamiento predeterminado o alguno, o todos los siguientes (vea el tema SET DATASESSION en el archivo ayuda para una lista completa de parámetros afectados):
* SET MULTILOCKS - Debe ser ON para permitir buffer, predeterminado OFF
* SET DELETED - Predeterminado OFF
* SET DATABASE - "No database" es el predeterminado en una sesión Privada
* SET EXCLUSIVE - El predeterminado es OFF para una sesión Privada
* SET LOCK - Predeterminado OFF
* SET COLLATE - Predeterminado es "MACHINE"
* SET EXACT - Predeterminado es OFF
Lo segundo que necesita es especificar explícitamente el modo buffer de cada tabla utilizada en la función CursorSetProp() con el parámetro apropiado porque la configuración en la ventana Opciones no se puede aplicar a la sesión privada de datos.
Entonces, ¿qué modo de buffer debo utilizar en mis formulario?
Para nosotros la respuesta es sencilla. Siempre debe utilizar estrategia de buffer de tabla con bloqueo optimista (es decir modo de buffer 5). La razón es simplemente que, con la excepción de creación de un índice, no hay nada que pueda hacer en otro modo que no pueda hacer en este modo. Mientras el buffer de filas puede ser utilizado en desarrollo, no creemos que tienen cabida en una aplicación en funcionamiento. La razón es simplemente que existe muchas formas en las que puede ser desencadenada la función TableUpdate() implícito (causado por el movimiento del puntero de registro) y no todos los que están por debajo de nuestro control directo. Por ejemplo, la función KeyMatch() está definida en el archivo Ayuda, como;
Busca una clave de índice en una etiqueta o un archivo de índice.
Parece suficientemente inofensivo - seguramente buscar un archivo índice no puede causar problemas. Pero una nota (en la sección Observaciones justo al final del tema) indica que:
KEYMATCH( ) devuelve el puntero de registro al registro donde estaba originalmente antes de ejecutar KEYMATCH( ).
Aquí se bloquea! Seguramente "devuelve el puntero de registro" implica que mueve el puntero del cursor - lo que en efecto - hace. La consecuencia es que si está utilizando el buffer de filas y quiere verificar por clave duplicados utilizando keymatch(), puede realizar inmediatamente cualquier cambio pendiente. (Por supuesto, en la versión 6 o después pueden siempre utilizar en su lugar IndexSeek(). Sin embargo, el mismo problema surge cuando muchos de los comandos y funciones que operan sobre una tabla - especialmente el más viejo introducido en FoxPro antes los días de buffer (e.g. CALCULATE, SUM y AVERAGE).
Aun más importante, el hecho de que configure una tabla para buffer de tabla no lo previene de que la tabla como si en realidad hubiera buffer de filas. Ambas funciones TableUpdate() y TableRevert(). Esto puede significar que tiene que escribir un poco más de código; pero puede evitar muchos problemas.
Cambiar el modo de buffer de la tabla
Hemos dicho, al inicio de la última sesión, que puede utilizar siempre CursorSetProp() para establecer o cambiar el modo de buffer de una tabla. Esto es cierto; pero si la tabla ya ha tenido asignado un modo buffer, puede no ser tan sencillo porque al cambiar el estado de buffer forzaría a Visual FoxPro a verificar el estado de cualquier buffer existente.
Si la tabla tiene buffer de filas, y tiene cambios no confirmados, Visual FoxPro los envía y permite cambiar el modo. Si el destino tiene buffer de tablas, y trata de cambiar su modo de buffer mientras existen cambios no confirmados, Visual FoxPro se queja y manda el error 1545 ("El búfer de tablas para el alias "nombre" contiene cambios no confirmados"). Esto es un problema porque no puede indexar una tabla, o hacerla libre una tabla o cursor transactable, los que mientras la tabla tiene buffer, por tanto es la única vía de hacer estas cosas, temporalmente, a buffer de filas. Por supuesto, la solución es siempre suficiente - asegúrese sólo de que no hay cambios pendientes antes de que intente cambiar el modo de buffer.
4.. 00
Para asegurarse de que todos los usuarios de un entorno compartido disponen de un duplicado exacto y seguro del entorno, y que múltiples instancias de un formulario pueden funcionar independientemente, Visual FoxPro proporciona sesiones de datos.
Una sesión de datos es una representación del entorno de trabajo dinámico actual. Podría considerar la sesión de datos como un entorno de datos en miniatura dentro de una sesión de Visual FoxPro abierta en un equipo. Cada sesión de datos contiene:
Una copia de los elementos en el entorno de datos del formulario
Cursores que representan las tablas abiertas, sus índices y relaciones.
El concepto de una sesión de datos se entiende fácilmente cuando se considera lo que ocurre al abrir el mismo formulario simultáneamente en dos estaciones de trabajo diferentes en una aplicación multiusuario. En este caso, cada estación de trabajo ejecuta una sesión de Visual FoxPro diferente y, por tanto, tiene su propio conjunto de áreas de trabajo: cursores que representan las tablas base abiertas, los índices y las relaciones.
Sin embargo, si abre en un solo equipo múltiples instancias del mismo formulario en un solo proyecto, dentro de la misma sesión de Visual FoxPro, los formularios comparten la sesión de datos predeterminada, lo que representa un único entorno de trabajo dinámico. Cada instancia del formulario abierto en la misma sesión de Visual FoxPro usa el mismo conjunto de áreas de trabajo y las acciones en una única instancia de un formulario que mueven el puntero de registro en un área de trabajo afectan automáticamente a otras instancias del mismo formulario.
Usar sesiones privadas de datos
Si desea tener más control sobre múltiples instancias de un formulario, puede implementar sesiones privadas de datos. Cuando el formulario utiliza sesiones privadas de datos, Visual FoxPro crea una nueva sesión de datos para cada instancia del control Form, FormSet o Toolbar que crea la aplicación. Cada sesión privada de datos contiene:
Una copia diferente de cada tabla, índice y relación del entorno de datos del formulario.
Un número ilimitado de áreas de trabajo.
Punteros de registro para la copia de cada tabla, independientes de las tablas base del formulario.
El número de sesiones de datos disponibles está limitado sólo por la memoria y el espacio en disco disponible en el sistema.
Las sesiones privadas de datos se implementan al establecer la propiedad DataSession para el formulario. La propiedad DataSession tiene dos configuraciones:
¿1? Sesión predeterminada de datos (la configuración predeterminada).
¿2? Sesión privada de datos.
El valor predeterminado de la propiedad DataSession es 1.
Para activar las sesiones privadas de datos
Elija una de las opciones siguientes:
En el Diseñador de formularios, ¿establezca la propiedad DataSession del formulario como 2? Sesión privada de datos.
? ¿O bien?
En el código, establezca la propiedad DataSession a 2.
Por ejemplo, escriba:
frmFormName.DataSession = 2
Nota Sólo puede establecer la propiedad DataSession durante el diseño y, en tiempo de ejecución, esta propiedad es de sólo lectura.
Cuando un formulario utiliza sesiones privadas de datos, cada instancia de un formulario abierta en un solo equipo en una única sesión de Visual FoxPro usa su propio entorno de datos. El uso de sesiones privadas de datos es similar a la ejecución simultánea del mismo formulario desde diferentes estaciones de trabajo.
Múltiples sesiones de datos equivalentes
Identificar sesiones de datos
Cada sesión privada de datos se identifica por separado. Puede ver el contenido de cada sesión de datos en la ventana Sesión de datos. También puede cambiar la descripción de la sesión de datos mediante comandos en el código del evento Load.
Puede ver el número de identificación de cada sesión de datos mediante la propiedad de tiempo de ejecución DataSessionID. El ejemplo siguiente muestra la propiedad DataSessionID de un formulario denominado frmMiFormulario:
DO FORM frmMiFormulario
? FrmMiFormulario. DataSessionID
Si activa el formulario mediante la cláusula NAME, puede usar el nombre del formulario para tener acceso a la propiedad DataSessionID, como en el código siguiente:
DO FORM MiFormulario NAME one
? One. DataSessionID
La propiedad DataSessionID sirve para identificar una sesión de datos determinada. Evite cambiar la propiedad DataSessionID de una instancia de un formulario porque los controles dependientes de datos pierden sus orígenes de datos cuando se modifica esta propiedad.
Actualizar datos con múltiples instancias de un formulario
Mientras que las sesiones privadas de datos generan áreas de trabajo diferentes que contienen copias independientes de las tablas abiertas, índices y relaciones de un formulario, cada copia del formulario hace referencia a los mismos archivos de tablas base y de índices base subyacentes. Cuando un usuario actualiza un registro en una instancia de un formulario, se actualiza la tabla base a la que hace referencia el formulario. Los cambios realizados en otra instancia del formulario pueden verse al desplazarse por el registro modificado.
Los bloqueos realizados en registros o tablas en una sesión privada de datos son respetados por otras sesiones privadas de datos. Por ejemplo, si el usuario de la sesión de datos 1 pone un bloqueo en un registro, el usuario de la sesión de datos 2 no puede bloquear el registro. Si el usuario de la sesión 1 abre una tabla de forma exclusiva, el usuario de la sesión de datos 2 no puede abrir la tabla. Respetando los bloqueos realizados por otras sesiones de datos, Visual FoxPro protege la integridad de las actualizaciones en las tablas base subyacentes.
Personalizar el entorno de una sesión de datos
Debido a que las sesiones de datos controlan el alcance de determinados comandos SET, puede usar sesiones privadas de datos para establecer configuraciones personalizadas de comandos SET dentro de una sola sesión de Visual FoxPro.
Por ejemplo, el comando SET EXACT, que controla las reglas utilizadas al comparar cadenas de caracteres de diferentes longitudes, pertenece al ámbito de la sesión de datos actual. La configuración predeterminada de SET EXACT es Off, lo que especifica que, para ser equivalentes, las expresiones deben coincidir, carácter a carácter, hasta que se llega al final de las expresiones en el lado derecho. Tal vez desee activar búsquedas "borrosas" o equivalentes; para ello, establezca SET EXACT como OFF para la sesión de datos actual. Sin embargo, la aplicación podría contener un formulario determinado que requiriera coincidencias exactas. Podría establecer la propiedad DataSession como 2 para el formulario que requiere coincidencias exactas, para activar las sesiones privadas de datos y después establecer SET EXACT a ON para ese formulario. Si ejecuta un comando SET sólo para el formulario que utiliza sesiones privadas de datos, se mantiene intacta la configuración global de la sesión de Visual FoxPro a la vez que permite la configuración personalizada para un formulario determinado.
Ignorar la asignación automática de sesión de datos
Cuando las sesiones privadas de datos para un formulario están en uso, los cambios realizados en los datos de un formulario no se representan automáticamente en otras instancias del mismo formulario. Si desea que todas las instancias de un formulario tengan acceso a los mismos datos y reflejen automáticamente los cambios realizados en datos comunes, puede ignorar la asignación automática de sesión de datos.
Para ignorar la asignación automática de sesión de datos
Utilice uno de estos comandos:
SET DATASESSION TO 1
?O bien?
SET DATASESSION TO
Ambos comandos permiten controlar la sesión de datos predeterminada mediante la ventana Comandos y el Administrador de proyectos.
5.. esto es según si estas trabajando con buffer=5.. tendrás que poner
se le tabla
=tableupdate(.t.)
para guardar los cambio
'o
sele tabla
=tablerevert(.t.)
Para quitar los cambios..
Amigo espero no haberte saturado de información, puedes leer la mitad probar y después la otra mitad, y espero haberte ayudado... cualquier duda
[email protected] emmanuel carrillo ponce
Respuesta de renehs
1
No t epreocupes que no vas a tener problemas no disminución de potencia en el motor
trabaja son se le y el nombre de la tabla que es igual a decirle se le 2
Si quieres ahorarrte código en lugar de hacer esto
se le 1
Use maestro
Dale
Use maestro in 1
Use detalle in 2
trabaja son se le y el nombre de la tabla que es igual a decirle se le 2
Si quieres ahorarrte código en lugar de hacer esto
se le 1
Use maestro
Dale
Use maestro in 1
Use detalle in 2