Detección e informe de conflictos de RDA

El acceso a datos remotos (RDA) en Microsoft SQL Server Compact 3.5 (SQL Server Compact 3.5) proporciona un mecanismo limitado de elaboración de informes de conflictos para las filas que no se pueden actualizar en el equipo que ejecuta SQL Server durante una operación de inserción.

Aunque RDA no proporciona una resolución específica de la manera en que lo hace la replicación, SQL Server Compact 3.5 ofrece una tabla de errores que captura todas las filas con conflictos. Puede especificar la tabla de errores como parte del método Pull. Los errores que se produzcan durante la inserción quedarán registrados en esta tabla de errores. Gracias a la tabla de errores, es posible desarrollar aplicaciones que administren la detección y la elaboración de informes de conflictos.

Los cambios realizados en la base de datos de SQL Server Compact 3.5 que se inserten en el servidor se aplicarán en el orden en que se reciban. La tabla de SQL Server se actualiza para mostrar los cambios que ha realizado el último usuario.

En RDA se produce un conflicto cuando no se puede insertar una fila de SQL Server Compact 3.5 en SQL Server. RDA sólo admite seguimiento a nivel de fila. Por tanto, algunas filas son correctas, mientras que otras presentan errores, dependiendo de las opciones que se seleccionen en el método Push. Para realizar el seguimiento de conflictos en RDA, especifique TRACKINGON o TRACKINGON_INDEXES en el método Pull.

Puede evitar conflictos y errores al utilizar tablas con seguimiento RDA filtrando correctamente las tablas y utilizando una conexión de red estable al propagar los datos.

Cómo se producen los conflictos de RDA

Los cambios en una fila no se pueden aplicar al servidor por las siguientes razones:

• RDA realiza un seguimiento de las operaciones INSERT, UPDATE y DELETE específicamente para cada fila que haya cambiado en la tabla sobre la que se realice el seguimiento en el dispositivo. Por lo tanto, si se inserta una fila en el cliente con el mismo valor de clave principal que una fila que también se ha insertado en el servidor en la misma tabla, la inserción del cliente producirá un error porque la inserción ya se ha producido.
• Si la partición de los datos no se ha realizado correctamente para cada usuario, un usuario puede eliminar una fila al mismo tiempo que otro usuario intenta actualizarla.
• También se puede producir un error al intentar insertar las filas en el servidor, lo que daría lugar a un error si una inserción anterior hubiese sido interrumpida. Por ejemplo, supongamos que un usuario comienza a insertar sus datos en el servidor, que contiene inserciones, y, durante la inserción, la red pierde su conectividad. El cliente mostrará un mensaje indicando que se ha producido un error en la inserción debido a un error en la conectividad de la red. No obstante los cambios se han aplicado en el servidor. Cuando vuelve a estar disponible la conexión a la red para el cliente y el usuario intenta insertar otra vez los mismos datos, algunas de las filas no se podrán aplicar, ya que esas filas se insertaron anteriormente. En este caso, la aplicación debería hacer caso omiso de todos los errores de la tabla que se deban a errores por duplicación de clave principal basados en la segunda inserción.

Tablas de errores

RDA realiza un seguimiento de los conflictos de datos (filas que no se han podido aplicar al servidor debido a un error) devolviendo y almacenando los errores en una tabla de errores de la base de datos de SQL Server Compact 3.5 junto con la fila en la que se produjo el error. Definirá esta tabla en el método Pull. Más adelante, si se produce algún error durante una operación de inserción, se almacenará en la tabla de errores.

Cuando use el método Push, si no se puede aplicar una fila al servidor debido a un error, como una clave principal duplicada, hará referencia al nombre de la tabla de errores que definió originalmente en el método Pull para resolver la fila. La propiedad ErrorTableName del método Pull especifica el nombre de la tabla en la que se deben almacenar los errores de inserción. La tabla de errores se crea inmediatamente, pero al principio no contiene filas. Sólo se puede utilizar ErrorTableName cuando se especifica TRACKINGON o TRACKINGON_INDEXES en el método Pull.

Si se produce un error porque no se puede aplicar una fila durante el método Push, SQL Server Compact 3.5 inserta un registro en la tabla por cada error que se produce. Además de todas las columnas desde la tabla base, se agregarán tres columnas adicionales para identificar la causa y el momento del error. En la columna s_ErrorDate se especifica la fecha y hora en la que se produjo el error. La columna s_OLEDBErrorNumber contiene el HResult del error que se produjo al aplicar la fila al servidor. La columna s_OLEDBErrorString contiene una cadena de texto que describe el error. Cuando el método Push finaliza con errores producidos cuando intentó aplicar filas al servidor, se presentará una advertencia (SSCE_WRN_RDAERRORROWSRETURNED, valor 28800) a la aplicación, la cual examinará la tabla de errores para determinar su causa.

Mantener las tablas de errores

Las tablas de errores se eliminan automáticamente si se quita la tabla con seguimiento RDA asociada, incluso si aún existen filas en la tabla de errores. El programador debe resolver las filas que se consideren conflictos, ya que esas filas no pueden aplicarse en el servidor.

Para actualizar los datos del dispositivo es posible que sea necesario resolver correctamente el error que se produjo al insertar datos por primera vez en el servidor. Es recomendable almacenar los datos en la caché de la tabla de errores de modo que no se pierdan al eliminar la tabla sobre la que se realiza el seguimiento. También puede extraer los datos actualizados a una tabla con un nombre distinto al de la tabla sobre la que originalmente se realiza el seguimiento.

Resolver errores después de insertar datos

El error, almacenado en la tabla de errores junto con la fila que lo produjo, describe por qué no se pudo insertar, actualizar o eliminar la fila del servidor. En función del error, puede ser muy importante saber el estado actual de los datos en el servidor. La aplicación debe desarrollarse de manera que pueda controlar esta situación, ya que al eliminar la tabla sobre la que se realiza el seguimiento también se elimina la tabla de errores.

Errores y transacciones no procesadas por lotes

Durante las transacciones no procesadas por lotes (opción BATCHINGOFF cuando use el método Push), los conflictos se detectan a nivel de fila. La fila en la que se produce el conflicto se devuelve a la aplicación y se almacena en una tabla de errores especificada. Por ejemplo, si la aplicación intenta insertar en SQL Server una fila que no es válida, esa fila se devuelve a la aplicación y se almacena en la tabla de errores junto con un mensaje de error en el que se indica el conflicto.

Cuando una fila con un conflicto se devuelve a la tabla de errores, esa fila se quita de la tabla original. Puesto que la tabla no se deja en su estado original, resulta algo más complejo resolver el conflicto que ha ocurrido. Debe diseñar la aplicación de modo que permita al usuario corregir los datos que generan el conflicto. Para ello, es necesario volver a extraer la tabla del servidor a fin de resolver correctamente la situación.

Al eliminar la tabla del dispositivo, también se eliminará la tabla de errores. Debe almacenar las filas en la caché de la tabla de errores en una ubicación provisional o extraer los datos del servidor a una tabla diferente. Puesto que las filas que causan los problemas se extraen de la tabla de la base de datos de SQL Server Compact 3.5, es importante actualizar de nuevo la tabla con los datos del servidor correctos. Si la fila que produjo el error estaba actualizada originalmente, debe realizarse una actualización de la misma fila para que se procese correctamente en la siguiente inserción. Si la fila se ha actualizado pero la fila del servidor ha sido eliminada, debe agregarse la fila otra vez a la tabla e insertarse de nuevo para que la inserción se realice correctamente.

Errores y transacciones por lotes

RDA también admite una inserción por lotes (opción BATCHINGON cuando use el método Push) que requiere que todas las filas sean correctas para que se procese la inserción completa. Si se produce algún error en una fila, se produce un error en toda la transacción de inserción y no se actualiza ningún dato. Las filas con conflictos se copian en la tabla de errores. Esta es la opción aconsejada, dado que permite utilizar un mecanismo ligeramente más sencillo para resolver el conflicto. A diferencia de la inserción no procesada por lotes, la base de datos original basada en Microsoft Windows CE permanece intacta. Debe diseñar la aplicación de modo que permita al usuario corregir los datos con conflictos y combinarlos de nuevo en la base de datos original basada en Windows CE. Puesto que la fila original permanece intacta, dependiendo del error, podría no ser necesario volver a extraer los datos del servidor para determinar la resolución correcta de la fila. Por ejemplo, si la fila tuvo errores debido a una infracción de la integridad, se puede actualizar la fila en el dispositivo e invocar el método Push para intentar insertar los datos en el servidor. Esta opción también ofrecer un mantenimiento más limpio, ya que la tabla de errores se limpia automáticamente antes de copiar una fila con conflictos. En la tabla sólo aparecen los conflictos de la última operación de inserción.