Editar datos sin conexión y sincronizar
Las soluciones de ejemplo 04-EditRecords.mtd y 05-EditRecordsOnStart.mtd ilustran cómo editar datos sin conexión y conectarse únicamente para guardar los datos en una BD del servidor.
Estas soluciones están en la carpeta (Mis) Documentos: Altova\MobileTogetherDesigner8\MobileTogetherDesignerExamples\Tutorials\OfflineUsage. Abra los archivos en MobileTogether Designer y ejecute simulaciones (F5) para ver cómo funcionan.
Las dos soluciones guardan datos en una BD SQLite en el servidor AddressesIndexed.sqlite. La solución 04-EditRecords.mtd se diferencia de 05-EditRecordsOnStart.mtd en que los registros de la BD SQLite no aparecen en la pantalla de inicio de la primera solución, pero sí en la de la segunda.
Descripción de las soluciones de ejemplo
La solución de ejemplo 04-EditRecords.mtd (imagen siguiente) muestra los datos de la BD en una tabla y permite a los usuarios editar esos datos. Los campos de la tabla están vinculados a la fuente de página \$PERSISTENT. Esto significa que (i) lo que aparece en la tabla es el contenido de \$PERSISTENT y (ii) los cambios que realice en la tabla se guardan en \$PERSISTENT.
Cuando se inicia la solución 04-EditRecords.mtd la tabla está vacía (imagen siguiente). La razón es que la fuente de página de la tabla es \$PERSISTENT, que está vacía. Observe que la fuente de página \$DB1 también está vacía. El motivo es que se ha configurado como Cargar datos = No automáticamente. En el panel de fuentes de página haga clic con el botón derecho en \$DB1 para ver el valor de su opción Cargar datos.
En la solución estos son los cambios que puede hacer al editar los datos:
•Puede añadir un registro nuevo (una fila) a la tabla y editar sus campos. Para añadir una fila nueva haga clic en el icono Más que hay a la derecha de la última fila (imágenes anterior y siguiente). Una vez haya añadido una fila nueva, los datos de esa fila se almacenan en \$PERSISTENT (imagen siguiente).
•En la solución puede eliminar una fila haciendo clic en el icono Menos correspondiente (imagen anterior).
•Los datos de \$PERSISTENT se pueden guardar en el servidor haciendo clic en Guardar en BD. Para más información consulte el apartado Guardar datos mediante claves primarias y OriginalRowSets, más abajo.
•Al hacer clic en Actualizar (dentro de un círculo rojo en la imagen siguiente) se descargan todas las filas con datos del servidor a \$DB1 y de ahí se copian a \$PERSISTENT (consulte las acciones del evento OnPageRefresh tal y como se definió en la pestaña de este evento). Cualquier información que estuviera previamente en \$PERSISTENT antes de actualizar se borra. Las filas de \$PERSISTENT aparecen en la tabla, por lo que en la tabla ahora se ven todos los registros del servidor. Observe que la configuración del acceso al servidor de \$DB1 es A petición. Esto garantiza que solamente se contacte con el servidor cuando se hace una petición al servidor, como cuando se vuelven a cargar los datos de la BD. Y esto significa que los usuarios pueden trabajar sin conexión hasta que necesiten cargar datos en el servidor.
Configuración
En esta tabla puede ver la configuración básica de la solución (04-EditRecords.mtd).
04-EditRecords.mtd | Efecto |
Cargar datos (de \$DB1) = No automáticamente | Los datos de BD del servidor no aparecen al iniciar la solución. |
Acceso al servidor (de \$DB1) = A petición | El cliente se conecta con el servidor solo cuando es necesario para ejecutar una acción. |
AlActualizarPágina vuelve a cargar los datos de BD desde el servidor, elimina nodos de \$PERSISTENT y anexa los nodos nuevos de \$DB1 a \$PERSISTENT. | Al actualizar la página, \$DB1 se vuelve a cargar con datos del servidor, que se copian en \$PERSISTENT. De esta forma la tabla contiene los datos más recientes del servidor. |
Cargar todos los datos para editar al iniciar la solución
Cuando se inicia la solución 04-EditRecords.mtd la tabla está vacía porque \$PERSISTENT está vacía. Si quiere que aparezcan todos los datos de la BD en la tabla puede usar el método siguiente, que también se usó en 05-EditRecordsOnStart.mtd. Para ver la configuración, abra 05-EditRecordsOnStart.mtd y consulte la definición del evento AlActualizarPágina en la página de la solución.
1.Como queremos que las acciones se ejecuten al iniciar la solución, las creamos en el evento AlCargarPágina de la página de inicio de la solución.
2.Vuelva a cargar \$DB1 con la acción Volver a cargar. Esta acción descarga todos los datos de BD del servidor a \$DB1 (cuando se inicia la solución),
3.Elimine todos los registros de \$PERSISTENT con la acción Eliminar nodos.
4.Copie todos los nodos de los registros de \$DB1 a \$PERSISTENT con la acción Actualizar nodos. Una vez los datos se han anexado a la estructura \$PERSISTENT, esta aparecerá automáticamente en la tabla. Esto se debe a que los controles de las celdas de la tabla contienen enlaces de fuente de página a los nodos de la fuente de página \$PERSISTENT.
Guardar los datos editados usando claves primarias y OriginalRowSets
Tanto en 04-EditRecords.mtd como en 05-EditRecordsOnStart.mtd, la configuración para crear un nodo OriginalRowSet se ha establecido en true. Esta configuración se activa con un comando de conmutación del menú contextual de la fuente de página. En nuestros dos ejemplos, siempre que se actualiza la página (con el botón Actualizar) se vuelve a cargar la fuente de página \$DB1 desde el servidor y se ejecutan dos pasos importantes: (I) se crea un nodo OriginalRowSet en \$DB1; este nodo contiene una copia exacta del nodo de la estructura RowSet (es decir, todas las filas de la BD del servidor) y (ii) se copian los nodos RowSet y OriginalRowSet de \$DB1 a la estructura \$PERSISTENT. Así sabemos qué filas estaban presentes originalmente en la tabla antes de empezar a editar: podemos ver las filas editadas en RowSet, mientras que las filas originales están en OriginalRowSet.
Si editamos la tabla, es decir, si añadimos o eliminamos filas, en \$PERSISTENT el número de filas en RowSet y OriginalRowSet será distinto. Cada fila se identifica por un campo de clave primaria único llamado ID que puede no aceptar valores nulos y está configurado automáticamente para incrementar automáticamente un número entero cada vez que se añade una línea.
Cuando se guardan datos en la BD del servidor, este es el mecanismo que se usa:
1.\$DB1 se vuelve a cargar con la acción Volver a cargar.
2.Desde \$DB1/RowSet se eliminan las filas que tienen el mismo identificador que las filas de \$PERSISTENT/OriginalRowset. Esto garantiza que se eliminen todas las filas originales (antes de editarlas) de \$DB1/RowSet.
3.Las filas de \$PERSISTENT/Rowset se copian en \$DB1/RowSet con la acción Anexar nodo(s). Estas son las filas nuevas, editadas y sin editar, de \$PERSISTENT/Rowset que queremos guardar en el servidor. Las filas que se han eliminado de la tabla no se encuentran en este conjunto de filas, por lo que no se copiarán en \$DB1. Como resultado, \$DB1 ahora contiene solamente las filas que queremos volver a guardar en el servidor.
4.Con la acción Guardar se guardan en la BD SQLite del servidor las modificaciones realizadas en los datos de \$DB1.