Enviando dados por push do cliente para o servidor
O envio de dados por push de um cliente para um servidor inclui a propagação de alterações do Microsoft SQL Server Compact 3.5 (SQL Server Compact 3.5) novamente para uma tabela do SQL Server. Para obter mais informações, consulte Método Push.
O aplicativo deve ter criado a tabela local do SQL Server Compact 3.5 chamando o método Pull com a opção de controle definida como ativada.
Os métodos controlados Pull e Push do RDA usam o controle de simultaneidade otimista. O SQL Server não mantém o bloqueio de registros puxados. Quando o aplicativo chama Push, as alterações feitas no banco de dados local do SQL Server Compact 3.5 são aplicadas incondicionalmente ao banco de dados do SQL Server. Isso pode fazer com que as alterações feitas por outros usuários do banco de dados do SQL Server sejam perdidas.
Processando em lotes
RDA_BATCHOPTION especifica se o SQL Server Compact 3.5 deve processar em lotes as alterações que estão sendo enviadas para a tabela do SQL Server. A configuração padrão é BATCHINGOFF, onde as alterações (inserção, atualização e exclusão) são aplicadas à tabela do SQL Server como transações individuais. Cada transação não depende de outra para ser bem-sucedida. BATCHINGON especifica que todas as alterações sejam enviadas como uma única transação. Neste caso, todas as alterações devem obter êxito para que a transação seja bem-sucedida. Se uma alteração falhar, toda a transação falhará e nenhuma alteração será aplicada à tabela do SQL Server. Embora BATCHINGON não seja a opção padrão, alguns desenvolvedores podem considerá-la um mecanismo mais fácil de ser usado na criação do código de resolução de conflitos. Para obter mais informações, consulte Detecção e relatórios de conflitos RDA.
BATCHINGON e BATCHINGOFF retornam todos os erros à tabela de erros e não apenas o primeiro erro que ocorre. Por exemplo, se BATCHINGON for especificado e três dentre cinco alterações falharem, nenhuma alteração será aplicada e as três falhas serão armazenadas na tabela de erros. Se BATCHINGOFF for especificado, as mesmas três falhas serão armazenadas na tabela de erros e as outras duas alterações serão aplicadas à tabela do SQL Server.
Transações não processadas em lotes
Durante transações não processadas em lotes (opção BATCHINGOFF), os conflitos são detectados nas linhas. A linha em conflito é retornada ao aplicativo e armazenada em uma tabela de erros especificada. Por exemplo, se o aplicativo tentar enviar por push ao SQL Server uma linha que não seja válida, essa linha será retornada ao aplicativo e será 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 do banco de dados original no dispositivo. Você deve fazer com que o design do aplicativo permita ao usuário corrigir os dados conflitantes e mesclá-los novamente no banco de dados original baseado no Windows Mobile.
Transações em lotes
O RDA também dá suporte a um push em lotes (opção BATCHINGON), no qual é necessário que todas as linhas sejam bem-sucedidas para que todo o push seja processado. Se uma linha falhar, toda a transação push falhará e nenhum dado será atualizado. As linhas conflitantes são copiadas para a tabela de erros. Ao contrário do push não processado em lotes, o banco de dados original baseado no Windows Mobile permanece intacto. Você deve fazer com que o design do aplicativo permita ao usuário corrigir os dados conflitantes e mesclá-los novamente no banco de dados original baseado no Windows Mobile. A tabela de erros é limpa automaticamente antes que uma linha conflitante seja copiada, de forma que somente os conflitos da última operação push permaneçam na tabela.
Consulte também
Outros recursos
Como enviar dados por push usando o objeto RDA (programaticamente)