Trabajar con Change Tracking (SQL Server)

Las aplicaciones que usan el seguimiento de cambios deben poder obtener cambios de seguimiento, aplicar estos cambios a otro almacén de datos y actualizar la base de datos de origen. En este tema se describe cómo realizar estas tareas y también el rol que desempeña el seguimiento de cambios cuando se produce una conmutación por error y se debe restaurar una base de datos a partir de una copia de seguridad.

Obtención de cambios mediante funciones de seguimiento de cambios

Describe cómo usar las funciones de seguimiento de cambios para obtener cambios e información sobre los cambios realizados en una base de datos.

Acerca de las funciones de seguimiento de cambios

Las aplicaciones pueden utilizar las funciones siguientes para obtener los cambios que se realizan en una base de datos e información sobre ellos:

FUNCIÓN CHANGETABLE(CHANGES ...)
Esta función de conjunto de filas se usa para consultar información de cambios. La función consulta los datos almacenados en las tablas internas de seguimiento de cambios. La función devuelve un conjunto de resultados que contiene las claves principales de las filas que han cambiado junto con otra información de cambio, como la operación, las columnas actualizadas y la versión de la fila.

CHANGETABLE(CHANGES ...) toma una última versión de sincronización como argumento. La última versión de sincronización se obtiene mediante la variable @last_synchronization_version. La semántica de la última versión de sincronización es la siguiente:

• El cliente que realiza la llamada ha obtenido cambios y conoce todos los cambios hasta la última versión de sincronización.

• CHANGETABLE(CHANGES ...) devolverá todos los cambios que se han producido después de la última versión de sincronización.

  En la ilustración siguiente se muestra cómo se usa CHANGETABLE(CHANGES ...) para obtener los cambios.

  

Función CHANGE_TRACKING_CURRENT_VERSION()
Se usa para obtener la versión actual que se usará la próxima vez al consultar los cambios. Esta versión representa la versión de la última transacción confirmada.

función CHANGE_TRACKING_MIN_VALID_VERSION()
Se usa para obtener la versión mínima válida que un cliente puede tener y seguir obteniendo resultados válidos de CHANGETABLE(). El cliente debe comprobar la última versión de sincronización con el valor devuelto por esta función. Si la última versión de sincronización es menor que la versión devuelta por esta función, el cliente no podrá obtener resultados válidos de CHANGETABLE() y tendrá que reinicializar.

Obtención de datos iniciales

Antes de que una aplicación pueda obtener los cambios por primera vez, la aplicación debe enviar una consulta para obtener los datos iniciales y la versión de sincronización. La aplicación debe obtener los datos adecuados directamente de la tabla y, a continuación, usar CHANGE_TRACKING_CURRENT_VERSION() para obtener la versión inicial. Esta versión se pasará a CHANGETABLE(CHANGES ...) la primera vez que se obtengan los cambios.

En el ejemplo siguiente se muestra cómo obtener la versión de sincronización inicial y el conjunto de datos inicial.

    -- Obtain the current synchronization version. This will be used next time that changes are obtained.  
    SET @synchronization_version = CHANGE_TRACKING_CURRENT_VERSION();  
  
    -- Obtain initial data set.  
    SELECT  
        P.ProductID, P.Name, P.ListPrice  
    FROM  
        SalesLT.Product AS P  

Uso de las Funciones de Seguimiento de Cambios para Obtener Cambios

Para obtener las filas modificadas de una tabla e información sobre los cambios, use CHANGETABLE(CHANGES...). Por ejemplo, la consulta siguiente obtiene los cambios de la SalesLT.Product tabla.

SELECT  
    CT.ProductID, CT.SYS_CHANGE_OPERATION,  
    CT.SYS_CHANGE_COLUMNS, CT.SYS_CHANGE_CONTEXT  
FROM  
    CHANGETABLE(CHANGES SalesLT.Product, @last_synchronization_version) AS CT  
  

Normalmente, un cliente querrá obtener los datos más recientes de una fila en lugar de solo las claves principales de la fila. Por lo tanto, una aplicación combinaría los resultados de CHANGETABLE(CHANGES ...) con los datos de la tabla de usuario. Por ejemplo, la siguiente consulta se combina con la tabla SalesLT.Product para obtener los valores de las columnas Name y ListPrice . Observe el uso de la propiedad OUTER JOIN. Esto es necesario para asegurarse de que la información sobre los cambios se devuelve para las filas que han sido eliminadas de la tabla de usuario.

SELECT  
    CT.ProductID, P.Name, P.ListPrice,  
    CT.SYS_CHANGE_OPERATION, CT.SYS_CHANGE_COLUMNS,  
    CT.SYS_CHANGE_CONTEXT  
FROM  
    SalesLT.Product AS P  
RIGHT OUTER JOIN  
    CHANGETABLE(CHANGES SalesLT.Product, @last_synchronization_version) AS CT  
ON  
    P.ProductID = CT.ProductID  

Para obtener la versión para su uso en la siguiente enumeración de cambios, use CHANGE_TRACKING_CURRENT_VERSION(), como se muestra en el ejemplo siguiente.

SET @synchronization_version = CHANGE_TRACKING_CURRENT_VERSION()  

Cuando una aplicación obtiene cambios, debe usar CHANGETABLE(CHANGES...) y CHANGE_TRACKING_CURRENT_VERSION(), como se muestra en el ejemplo siguiente.

-- Obtain the current synchronization version. This will be used the next time CHANGETABLE(CHANGES...) is called.  
SET @synchronization_version = CHANGE_TRACKING_CURRENT_VERSION();  
  
-- Obtain incremental changes by using the synchronization version obtained the last time the data was synchronized.  
SELECT  
    CT.ProductID, P.Name, P.ListPrice,  
    CT.SYS_CHANGE_OPERATION, CT.SYS_CHANGE_COLUMNS,  
    CT.SYS_CHANGE_CONTEXT  
FROM  
    SalesLT.Product AS P  
RIGHT OUTER JOIN  
    CHANGETABLE(CHANGES SalesLT.Product, @last_synchronization_version) AS CT  
ON  
    P.ProductID = CT.ProductID  

Números de versión

Una base de datos que tiene habilitado el seguimiento de cambios tiene un contador de versiones que aumenta a medida que se realizan cambios en las tablas de seguimiento de cambios. Cada fila modificada tiene un número de versión asociado. Cuando se envía una solicitud a una aplicación para consultar los cambios, se llama a una función que proporciona un número de versión. La función devuelve información sobre todos los cambios realizados desde esa versión. De alguna manera, la versión de seguimiento de cambios es similar en concepto al tipo de datos rowversion.

Validación de la última versión sincronizada

La información sobre los cambios se mantiene durante un tiempo limitado. El período de tiempo se controla mediante el parámetro CHANGE_RETENTION que se puede especificar como parte de ALTER DATABASE.

Tenga en cuenta que el tiempo especificado para CHANGE_RETENTION determina con qué frecuencia todas las aplicaciones deben solicitar cambios de la base de datos. Si una aplicación tiene un valor para last_synchronization_version que es anterior a la versión de sincronización mínima válida para una tabla, esa aplicación no puede realizar una enumeración de cambios válida. Esto se debe a que es posible que se haya limpiado alguna información de cambio. Antes de que una aplicación obtenga los cambios mediante CHANGETABLE(CHANGES ...), la aplicación debe validar el valor de last_synchronization_version que planea pasar a CHANGETABLE(CHANGES ...). Si el valor de last_synchronization_version no es válido, esa aplicación debe reinicializar todos los datos.

En el ejemplo siguiente se muestra cómo comprobar la validez del valor de last_synchronization_version para cada tabla.

-- Check individual table.  
IF (@last_synchronization_version < CHANGE_TRACKING_MIN_VALID_VERSION(  
                                   OBJECT_ID('SalesLT.Product')))  
BEGIN  
  -- Handle invalid version and do not enumerate changes.  
  -- Client must be reinitialized.  
END  

Como se muestra en el ejemplo siguiente, la validez del valor de last_synchronization_version se puede comprobar en todas las tablas de la base de datos.

-- Check all tables with change tracking enabled  
IF EXISTS (  
  SELECT COUNT(*) FROM sys.change_tracking_tables  
  WHERE min_valid_version > @last_synchronization_version )  
BEGIN  
  -- Handle invalid version & do not enumerate changes  
  -- Client must be reinitialized  
END  

Uso del seguimiento de columnas

El seguimiento de columnas permite a las aplicaciones obtener los datos solo para las columnas que han cambiado en lugar de toda la fila. Por ejemplo, considere el escenario en el que una tabla tiene una o varias columnas que son grandes, pero rara vez cambian; y también tiene otras columnas que cambian con frecuencia. Sin el seguimiento de columnas, una aplicación solo puede determinar que una fila ha cambiado y tendría que sincronizar todos los datos que incluyen los datos de columna grandes. Sin embargo, mediante el seguimiento de columnas, una aplicación puede determinar si los datos de columna grandes han cambiado y solo sincronizar los datos si ha cambiado.

La información de seguimiento de columnas aparece en la columna SYS_CHANGE_COLUMNS que es devuelta por la función CHANGETABLE(CHANGES ...).

El seguimiento de columnas se puede usar para que se devuelva NULL para una columna que no haya cambiado. Si la columna se puede cambiar a NULL, se debe devolver una columna independiente para indicar si la columna ha cambiado.

En el ejemplo siguiente, la CT_ThumbnailPhoto columna será NULL si esa columna no cambió. Esta columna también podría ser NULL porque se cambió a NULL: la aplicación puede usar la columna CT_ThumbNailPhoto_Changed para determinar si la columna cambió.

DECLARE @PhotoColumnId int = COLUMNPROPERTY(  
    OBJECT_ID('SalesLT.Product'),'ThumbNailPhoto', 'ColumnId')  
  
SELECT  
    CT.ProductID, P.Name, P.ListPrice, -- Always obtain values.  
    CASE  
           WHEN CHANGE_TRACKING_IS_COLUMN_IN_MASK(  
                     @PhotoColumnId, CT.SYS_CHANGE_COLUMNS) = 1  
            THEN ThumbNailPhoto  
            ELSE NULL  
      END AS CT_ThumbNailPhoto,  
      CHANGE_TRACKING_IS_COLUMN_IN_MASK(  
                     @PhotoColumnId, CT.SYS_CHANGE_COLUMNS) AS  
                                   CT_ThumbNailPhoto_Changed  
     CT.SYS_CHANGE_OPERATION, CT.SYS_CHANGE_COLUMNS,  
     CT.SYS_CHANGE_CONTEXT  
FROM  
     SalesLT.Product AS P  
INNER JOIN  
     CHANGETABLE(CHANGES SalesLT.Product, @last_synchronization_version) AS CT  
ON  
     P.ProductID = CT.ProductID AND  
     CT.SYS_CHANGE_OPERATION = 'U'  

Obtención de resultados coherentes y correctos

La obtención de los datos modificados para una tabla requiere varios pasos. Tenga en cuenta que se podrían devolver resultados incoherentes o incorrectos si no se consideran y controlan determinados problemas.

Por ejemplo, para obtener los cambios realizados en una tabla Sales y en la tabla SalesOrders, una aplicación realizaría los pasos siguientes:

1. Verifique la última versión sincronizada utilizando la función CHANGE_TRACKING_MIN_VALID_VERSION().

2. Obtenga la versión que se puede usar para obtener el cambio la próxima vez mediante CHANGE_TRACKING_CURRENT_VERSION().

3. Obtenga los cambios de la tabla Sales mediante CHANGETABLE(CHANGES ...).

4. Obtenga los cambios de la tabla SalesOrders mediante CHANGETABLE(CHANGES ...).

En la base de datos se producen dos procesos que pueden afectar a los resultados devueltos por los pasos anteriores:

• El proceso de limpieza se ejecuta en segundo plano y quita la información de seguimiento de cambios anterior al período de retención especificado.

  El proceso de limpieza es un proceso en segundo plano independiente que usa el período de retención especificado al configurar el seguimiento de cambios para la base de datos. El problema es que el proceso de limpieza puede producirse en el tiempo entre el momento en que se validó la última versión de sincronización y cuando se realiza la llamada a CHANGETABLE(CHANGES...). Una última versión de sincronización que solo era válida podría dejar de ser válida en el momento en que se obtienen los cambios. Por lo tanto, es posible que se devuelvan resultados incorrectos.

• Las operaciones DML en curso se producen en las tablas Sales y SalesOrders, como las siguientes:

  • Los cambios se pueden realizar en las tablas una vez se haya obtenido la versión para la siguiente vez mediante CHANGE_TRACKING_CURRENT_VERSION(). Por lo tanto, se pueden devolver más cambios de lo esperado.

  • Una transacción podría realizarse en el tiempo entre la llamada para obtener cambios de la tabla de Ventas y la llamada para obtener cambios de la tabla de Pedidos de Ventas. Por lo tanto, los resultados de la tabla "SalesOrder" podrían tener un valor de clave foránea que no existe en la tabla "Sales".

Para superar los desafíos enumerados anteriormente, se recomienda usar el aislamiento de instantáneas. Esto ayudará a garantizar la coherencia de la información de modificación y evitar las condiciones de competición relacionadas con la tarea de depuración en segundo plano. Si no usa transacciones de instantáneas, el desarrollo de una aplicación que usa el seguimiento de cambios podría requerir mucho más esfuerzo.

Uso de aislamiento por instantáneas

El seguimiento de cambios se ha diseñado para funcionar bien con el aislamiento de instantáneas. La opción de aislamiento de instantáneas debe estar habilitada en la base de datos. Todos los pasos necesarios para obtener los cambios deben incluirse dentro de una transacción de instantánea. Esto garantizará que todas las modificaciones realizadas en los datos mientras se obtienen cambios no serán visibles para las consultas dentro de la transacción de instantánea.

Para obtener datos dentro de una transacción de captura instantánea, siga los siguientes pasos:

1. Establezca el nivel de aislamiento de la transacción en nivel de instantánea e inicie una transacción.

2. Valide la versión de sincronización más reciente usando CHANGE_TRACKING_MIN_VALID_VERSION().

3. Obtenga la versión que se usará la próxima vez mediante CHANGE_TRACKING_CURRENT_VERSION().

4. Obtenga los cambios de la tabla "Sales" mediante CHANGETABLE(CHANGES ...)

5. Obtenga los cambios en la tabla Salesorders utilizando CHANGETABLE(CHANGES ...)

6. Confirme la transacción.

Algunos puntos que deben recordarse ya que todos los pasos para realizar los cambios están dentro de una transacción de instantánea:

• Si la limpieza se produce después de validar la última versión de sincronización, los resultados de CHANGETABLE(CHANGES ...) seguirán siendo válidos, ya que las operaciones de eliminación realizadas por la limpieza no estarán visibles dentro de la transacción.

• Los cambios realizados en la tabla Sales o en la tabla SalesOrders después de obtener la siguiente versión de sincronización no serán visibles y las llamadas a CHANGETABLE(CHANGES ...) nunca devolverán cambios con una versión posterior a la que devolvió CHANGE_TRACKING_CURRENT_VERSION(). También se mantendrá la coherencia entre la tabla Sales y la tabla SalesOrders, ya que las transacciones confirmadas en el tiempo entre las llamadas a CHANGETABLE(CHANGES ...) no serán visibles.

En el ejemplo siguiente se muestra cómo está habilitado el aislamiento de instantáneas para una base de datos.

-- The database must be configured to enable snapshot isolation.  
ALTER DATABASE AdventureWorksLT  
    SET ALLOW_SNAPSHOT_ISOLATION ON;  

Se usa una transacción de instantánea como se indica a continuación:

SET TRANSACTION ISOLATION LEVEL SNAPSHOT;  
BEGIN TRAN  
  -- Verify that version of the previous synchronization is valid.  
  -- Obtain the version to use next time.  
  -- Obtain changes.  
COMMIT TRAN  

Para obtener más información sobre las transacciones instantáneas, consulte SET TRANSACTION ISOLATION LEVEL (Transact-SQL).

Alternativas al uso del aislamiento de instantáneas

Hay alternativas al uso del aislamiento de instantáneas, pero requieren más trabajo para asegurarse de que se cumplen todos los requisitos de la aplicación. Para asegurarse de que el last_synchronization_version es válido y el proceso de limpieza no quita los datos antes de obtener los cambios, haga lo siguiente:

1. Compruebe last_synchronization_version después de las llamadas a CHANGETABLE().

2. Compruebe last_synchronization_version como parte de cada consulta para obtener los cambios mediante CHANGETABLE().

Los cambios pueden producirse después de obtener la versión de sincronización de la siguiente enumeración. Hay dos maneras de controlar esta situación. La opción que se usa depende de la aplicación y de cómo puede controlar los efectos secundarios de cada enfoque:

• Omita los cambios que tengan una versión mayor que la nueva versión de sincronización.

  Este enfoque tiene el efecto secundario de que una fila nueva o actualizada quedará omitida si se creó o actualizó antes de la nueva versión de sincronización, pero luego se actualiza nuevamente. Si hay una nueva fila, podría producirse un problema de integridad referencial si había una fila en otra tabla que se creó que hizo referencia a la fila omitida. Si hay una fila existente actualizada, se omitirá la fila y no se sincronizará hasta la próxima vez.

• Incluya todos los cambios, incluso aquellos que tengan una versión mayor que la nueva versión de sincronización.

  Las filas que tienen una versión mayor que la nueva versión de sincronización se obtendrán de nuevo en la siguiente sincronización. Esto debe esperarse y controlarse por la aplicación.

Además de las dos opciones anteriores, puede diseñar el enfoque que combina ambas opciones, dependiendo de la operación. Por ejemplo, puede que desee una aplicación para la que sea mejor omitir los cambios más recientes que la siguiente versión de sincronización en la que se creó o eliminó la fila, pero no se omiten las actualizaciones.

Cómo gestiona el seguimiento de cambios en una base de datos

Algunas aplicaciones que usan el seguimiento de cambios realizan la sincronización bidireccional con otro almacén de datos. Es decir, los cambios realizados en la base de datos de SQL Server se actualizan en el otro almacén de datos y los cambios realizados en el otro almacén se actualizan en la base de datos de SQL Server.

Cuando una aplicación actualiza la base de datos local con cambios de otro almacén de datos, la aplicación debe realizar las siguientes operaciones:

• Compruebe si hay conflictos.

  Un conflicto se produce cuando se cambian los mismos datos al mismo tiempo en ambos almacenes de datos. La aplicación debe poder comprobar si hay un conflicto y obtener suficiente información para permitir que el conflicto se resuelva.

• Almacenar información de contexto de la aplicación.

  La aplicación almacena los datos que tienen información sobre el seguimiento de cambios. Esta información estaría disponible junto con otra información de seguimiento de cambios cuando se obtuvieron cambios de la base de datos local. Un ejemplo común de esta información contextual es un identificador para el almacén de datos que era el origen del cambio.

Para realizar las operaciones anteriores, una aplicación de sincronización puede usar las funciones siguientes:

• CHANGETABLE(VERSION...)

  Cuando una aplicación realiza cambios, puede usar esta función para comprobar si hay conflictos. La función obtiene la información de seguimiento de cambios más reciente de una fila especificada en una tabla de seguimiento de cambios. La información de seguimiento de cambios incluye la versión de la fila que se cambió por última vez. Esta información permite a una aplicación determinar si la fila se cambió después de la última vez que se sincronizó la aplicación.

• WITH CHANGE_TRACKING_CONTEXT

  Una aplicación puede usar esta cláusula para almacenar datos de contexto.

Comprobación de conflictos

En un escenario de sincronización bidireccional, la aplicación cliente debe determinar si no se ha actualizado una fila desde que la aplicación obtuvo los cambios por última vez.

En el ejemplo siguiente se muestra cómo usar la función CHANGETABLE(VERSION ...) para comprobar si hay conflictos de la manera más eficaz, sin una consulta independiente. En el ejemplo, CHANGETABLE(VERSION ...) determina para SYS_CHANGE_VERSION la fila especificada por @product id. CHANGETABLE(CHANGES ...) puede obtener la misma información, pero eso sería menos eficaz. Si el valor de SYS_CHANGE_VERSION para la fila es mayor que el valor de @last_sync_version, hay un conflicto. Si hay un conflicto, la fila no se actualizará. La ISNULL() comprobación es necesaria porque es posible que no haya información de cambios disponible para la fila. No existiría información de cambios si la fila no se hubiera actualizado desde que se habilitó el seguimiento de cambios o desde que se limpió la información de cambios.

-- Assumption: @last_sync_version has been validated.  
  
UPDATE  
    SalesLT.Product  
SET  
    ListPrice = @new_listprice  
FROM  
    SalesLT.Product AS P  
WHERE  
    ProductID = @product_id AND  
    @last_sync_version >= ISNULL (  
        SELECT CT.SYS_CHANGE_VERSION  
        FROM CHANGETABLE(VERSION SalesLT.Product,  
                        (ProductID), (P.ProductID)) AS CT),  
        0)  

El código siguiente puede comprobar el recuento de filas actualizado y puede identificar más información sobre el conflicto.

-- If the change cannot be made, find out more information.  
IF (@@ROWCOUNT = 0)  
BEGIN  
    -- Obtain the complete change information for the row.  
    SELECT  
        CT.SYS_CHANGE_VERSION, CT.SYS_CHANGE_CREATION_VERSION,  
        CT.SYS_CHANGE_OPERATION, CT.SYS_CHANGE_COLUMNS  
    FROM  
        CHANGETABLE(CHANGES SalesLT.Product, @last_sync_version) AS CT  
    WHERE  
        CT.ProductID = @product_id;  
  
    -- Check CT.SYS_CHANGE_VERSION to verify that it really was a conflict.  
    -- Check CT.SYS_CHANGE_OPERATION to determine the type of conflict:  
    -- update-update or update-delete.  
    -- The row that is specified by @product_id might no longer exist   
    -- if it has been deleted.  
END  

Establecer información de contexto

Mediante el uso de la cláusula WITH CHANGE_TRACKING_CONTEXT, una aplicación puede almacenar información de contexto junto con la información de cambio. A continuación, esta información se puede obtener de la columna SYS_CHANGE_CONTEXT que devuelve CHANGETABLE(CHANGES ...).

La información de contexto se usa normalmente para identificar el origen de los cambios. Si se puede identificar el origen del cambio, un almacén de datos puede usar esa información para evitar obtener cambios cuando se sincroniza de nuevo.

  -- Try to update the row and check for a conflict.  
  WITH CHANGE_TRACKING_CONTEXT (@source_id)  
  UPDATE  
     SalesLT.Product  
  SET  
      ListPrice = @new_listprice  
  FROM  
      SalesLT.Product AS P  
  WHERE  
     ProductID = @product_id AND  
     @last_sync_version >= ISNULL (  
         (SELECT CT.SYS_CHANGE_VERSION FROM CHANGETABLE(VERSION SalesLT.Product,  
         (ProductID), (P.ProductID)) AS CT),  
         0)  

Garantizar resultados coherentes y correctos

Una aplicación debe tener en cuenta el proceso de limpieza cuando valida el valor de @last_sync_version. Esto se debe a que los datos podrían haberse quitado después de llamar a CHANGE_TRACKING_MIN_VALID_VERSION(), pero antes de realizar la actualización.

-- Prerequisite is to ensure ALLOW_SNAPSHOT_ISOLATION is ON for the database.  
  
SET TRANSACTION ISOLATION LEVEL SNAPSHOT;  
BEGIN TRAN  
    -- Verify that last_sync_version is valid.  
    IF (@last_sync_version <  
CHANGE_TRACKING_MIN_VALID_VERSION(OBJECT_ID('SalesLT.Product')))  
    BEGIN  
       RAISERROR (N'Last_sync_version too old', 16, -1);  
    END  
    ELSE  
    BEGIN  
        -- Try to update the row.  
        -- Check @@ROWCOUNT and check for a conflict.  
    END  
COMMIT TRAN  

Seguimiento de cambios y restauración de datos

Las aplicaciones que requieren sincronización deben tener en cuenta el caso en el que una base de datos que tiene habilitado el seguimiento de cambios se revierte a una versión anterior de los datos. Esto puede ocurrir después de restaurar una base de datos desde una copia de seguridad, cuando hay una conmutación por error a un reflejo asincrónico de la base de datos o cuando se produce un error al usar el trasvase de registros. En el escenario siguiente se muestra el problema:

1. La tabla T1 tiene seguimiento de cambios, y la versión mínima válida es 50.

2. Una aplicación cliente sincroniza los datos en la versión 100 y obtiene información sobre todos los cambios entre las versiones 50 y 100.

3. Se realizan cambios adicionales en la tabla T1 después de la versión 100.

4. En la versión 120, se produce un error y el administrador de la base de datos restaura la base de datos con pérdida de datos. Después de la operación de restauración, la tabla contiene datos hasta la versión 70 y la versión mínima sincronizada sigue siendo 50.

   Esto significa que el almacén de datos sincronizado tiene datos que ya no existen en el almacén de datos principal.

5. T1 se actualiza muchas veces. Esto lleva la versión actual a la 130.

6. La aplicación cliente se sincroniza de nuevo y proporciona una última versión sincronizada de 100. El cliente valida este número correctamente porque 100 es mayor que 50.

   El cliente obtiene los cambios entre la versión 100 y la 130. En este momento, el cliente no sabe que los cambios entre 70 y 100 no son los mismos que antes. Los datos del cliente y el servidor no se sincronizan.

Tenga en cuenta que si la base de datos se recuperó a un punto después de la versión 100, no habría problemas con la sincronización. El cliente y el servidor sincronizarían los datos correctamente durante el siguiente intervalo de sincronización.

El seguimiento de cambios no proporciona soporte para recuperar datos perdidos. Sin embargo, hay dos opciones para detectar estos tipos de problemas de sincronización:

• Almacene un identificador de versión de base de datos en el servidor y actualice este valor siempre que se recupere una base de datos o pierda datos de otro modo. Cada aplicación cliente almacenaría el identificador y cada cliente tendría que validar este identificador cuando sincroniza los datos. Si se produce una pérdida de datos, los identificadores no coincidirán y los clientes reinicializarán. Un inconveniente es si la pérdida de datos no ha cruzado el último límite sincronizado, el cliente podría realizar una reinicialización innecesaria.

• Cuando un cliente consulta los cambios, registre el último número de versión de sincronización para cada cliente del servidor. Si hay un problema con los datos, los últimos números de versión sincronizados no coincidirían. Esto indica que se requiere una reinicialización.

Véase también

Seguimiento de cambios de datos (SQL Server)
Acerca del seguimiento de cambios (SQL Server)
Administrar el seguimiento de cambios (SQL Server)
Habilitar y deshabilitar el seguimiento de cambios (SQL Server)
CHANGETABLE (Transact-SQL)
CHANGE_TRACKING_MIN_VALID_VERSION (Transact-SQL)
SEGUIMIENTO_DE_CAMBIOS_VERSIÓN_ACTUAL (Transact-SQL)
WITH CHANGE_TRACKING_CONTEXT (Transact-SQL)