Detecção e relatórios de conflitos RDA

No Microsoft SQL Server Compact 3.5 (SQL Server Compact 3.5), o RDA fornece um mecanismo de relatórios de conflitos limitado para linhas que não podem ser atualizadas no computador que executa o SQL Server durante uma operação push.

Importante

As linhas em conflito no RDA são estritamente definidas como operações de inserção, atualização ou exclusão que falham devido a um erro quando enviadas por push do SQL Server Compact 3.5 para a tabela do SQL Server. As alterações nos dados por diferentes usuários não são consideradas conflitos quando não causam erros.

Embora o RDA não forneça um resolvedor específico para a replicação, o SQL Server Compact 3.5 fornece uma tabela de erros que identifica todas as linhas em conflito. Você pode especificar a tabela de erros como parte do método Pull. Todos os erros que ocorrem durante o push são gravados nessa tabela de erros. Usando a tabela de erros, você pode desenvolver aplicativos para gerenciar a detecção e os relatórios de conflitos.

As alterações feitas no banco de dados SQL Server Compact 3.5 que são enviadas por push ao servidor são aplicadas na ordem na qual foram recebidas. A tabela do SQL Server é atualizada para refletir as alterações feitas pelo último usuário.

No RDA, ocorre um conflito quando uma linha não pode ser enviada por push do SQL Server Compact 3.5 para o SQL Server. O RDA oferece suporte apenas ao controle no nível de linha. Assim, algumas linhas obtêm êxito e outras falham, dependendo das opções selecionadas em um método Push. Para controlar conflitos no RDA, especifique TRACKINGON ou TRACKINGON_INDEXES no método Pull.

Você pode evitar conflitos e erros ao usar tabelas controladas pelo RDA filtrando corretamente as tabelas e usando uma conexão de rede estável ao propagar dados.

Como os conflitos do RDA ocorrem

Alterações em uma linha não podem ser aplicadas no servidor pelos seguintes motivos:

• O RDA controla operações de inserção, atualização e exclusão especificamente para cada linha que foi alterada na tabela controlada no dispositivo. Então, se uma linha for inserida no cliente com o mesmo valor de chave primária de uma linha que também foi inserida no servidor na mesma tabela, o push do cliente falhará com um erro porque a inserção já ocorreu.
• Se os dados não tiverem sido particionados corretamente para cada usuário, um usuário poderá excluir uma linha quando outro usuário estiver tentando atualizar a mesma linha.
• As linhas também podem falhar ao serem enviadas por push ao servidor, causando erros se um push anterior tiver sido interrompido. Por exemplo, um usuário começa a enviar seus dados por push para o servidor, que contém inserções, e durante o push a conectividade da rede é perdida. O cliente exibe uma mensagem informando que o push falhou devido à perda de conectividade da rede. No entanto, as alterações foram realmente aplicadas no servidor. Quando o cliente obtém novamente a conectividade da rede e o usuário tenta um segundo push dos mesmos dados, a aplicação de algumas das linhas falha porque elas foram inseridas durante o push anterior. Nesse caso, a aplicação deve ignorar todos os erros na tabela de erros com falha devido a uma duplicação de chave primária baseada no segundo push.

Tabelas de erros

O RDA controla conflitos de dados, linhas que não puderam ser aplicadas ao servidor devido a um erro, retornando e armazenando os erros em uma tabela de erros no banco de dados SQL Server Compact 3.5 juntamente com a linha que falhou. Você definirá essa tabela no método Pull. Depois, se ocorrer algum erro durante uma operação push, eles serão armazenados na tabela de erros.

Quando você usa o método Push, se uma linha não puder ser aplicada ao servidor devido a um erro, como uma chave primária duplicada, você fará referência ao nome da tabela de erros originalmente definida no método Pull para resolver a linha. A propriedade ErrorTableName do método Pull especifica o nome da tabela na qual os erros de push devem ser armazenados. A tabela de erros é criada imediatamente, mas primeiro não contém nenhuma linha. O ErrorTableName pode ser especificado apenas quando TRACKINGON ou TRACKINGON_INDEXES for especificado no método Pull.

Se ocorrer um erro porque uma linha não pode ser aplicada durante o método Push, o SQL Server Compact 3.5 irá inserir um registro na tabela para cada erro que ocorrer. Junto com todas as colunas da tabela base, três colunas adicionais são adicionadas para identificar o motivo e quando o erro ocorreu. A coluna s_ErrorDate especifica a data e a hora que ocorreu o erro. A coluna s_OLEDBErrorNumber especifica o HResult do erro que ocorreu quando você aplicou a linha ao servidor. A coluna s_OLEDBErrorString é a descrição de uma seqüência de erros. Quando o método Push é concluído e ocorrem erros quando ele tenta aplicar linhas ao servidor, um aviso (SSCE_WRN_RDAERRORROWSRETURNED, valor 28800) é relatado ao aplicativo e ele pode examinar a tabela de erros para determinar a causa dos erros.

Oferecendo manutenção às tabelas de erros

As tabelas de erros serão automaticamente excluídas se a tabela associada, controlada pelo RDA, for descartada, mesmo que as linhas ainda existam na tabela de erros. O desenvolvedor deve resolver as linhas que são consideradas conflitantes porque elas não podem ser aplicadas ao servidor.

A atualização de dados no dispositivo pode ser necessária para resolver corretamente o erro ocorrido quando os dados foram originalmente enviados por push ao servidor. Recomendamos que você armazene em cache os dados na tabela de erros para que não haja perda quando a tabela controlada for descartada. Como alternativa, você poderá efetuar pull dos dados atualizados em uma tabela que tenha um nome diferente da tabela controlada originalmente.

Resolvendo erros após um push de dados

O erro, armazenado na tabela de erros juntamente com a linha que falhou, descreve o motivo pelo qual a linha falhou ao ser inserida, atualizada ou excluída do servidor. Dependendo do erro, pode ser muito importante saber o estado atual dos dados no servidor. O aplicativo deve ser criado para lidar com essa situação, pois a exclusão da tabela controlada excluiu a tabela de erros.

Transações não processadas em lotes e erros

Durante transações não processadas em lotes (opção BATCHINGOFF quando você usa o método Push), os conflitos são detectados no nível de linha. A linha em conflito é retornada ao aplicativo e armazenada em uma tabela de erros especificada. Por exemplo, se o aplicativo tentar enviar por push uma linha que não seja válida para o SQL Server, essa linha será retornada ao aplicativo e armazenada na tabela de erros junto com uma mensagem de erro indicando o conflito.

Quando uma linha em conflito é retornada à tabela de erros, essa linha é removida da tabela original. Como a tabela não fica em seu estado original, é um pouco mais difícil resolver o conflito que ocorreu. Você deve projetar o aplicativo para permitir que o usuário corrija os dados conflitantes. Resolver corretamente a situação pode envolver um novo pull da tabela do servidor.

Descartar a tabela no dispositivo fará com que a tabela de erros seja descartada. Você deve armazenar em cache as linhas da tabela de erros em um local temporário ou efetuar pull dos dados do servidor em uma tabela diferente. Como as linhas ofensivas são movidas para fora da tabela no banco de dados SQL Server Compact 3.5, é importante que essas tabelas sejam atualizadas novamente com os dados de servidor corretos. Se a linha que falhou tiver sido atualizada originalmente, a mesma linha deve ser atualizada novamente para que haja êxito no push subseqüente. Se a linha tiver sido atualizada, mas a linha no servidor tiver sido excluída, ela deverá ser adicionada novamente na tabela e enviada por push mais uma vez para que a inserção tenha êxito.

Transações em lotes e erros

O RDA também oferece suporte a um push em lotes (opção BATCHINGON quando você usa o método Push) que requer o êxito de todas as linhas para processar o push completo. Se uma linha falhar, a transação push completa falhará e nenhum dado será atualizado. As linhas conflitantes são copiadas para a tabela de erros. Esta opção é preferencial, pois permite que um mecanismo um pouco mais simples resolva o conflito. Diferente do push não processado em lotes, o banco de dados original baseado no Microsoft Windows CE permanece intacto. Você deve projetar o aplicativo para permitir que o usuário corrija os dados conflitantes e mescle-os novamente no banco de dados original baseado no Windows CE. Como a linha original permanece intacta, dependendo do erro, talvez não seja necessário imediatamente efetuar novo pull dos dados do servidor para determinar a resolução correta da linha. Por exemplo, se a linha falhou devido a uma violação de integridade, a linha no dispositivo poderá ser atualizada e o método Push chamado para tentar enviar os dados por push para o servidor. Essa opção também fornece uma manutenção de limpeza, pois a tabela de erros é automaticamente limpa antes que a linha conflitante seja copiada. Existem na tabela apenas os conflitos da última operação push.