Início / dba / Perguntas / 187984
Accepted
Jack Scott
Asked: 2017-10-09 15:50:18 +0800 CST

UPDATE estranho resulta na presença de replicação de mesclagem

  • 772

Eu tenho um banco de dados front-end do MS Access que acessa um back-end do SQL Server. Isso (até onde sabemos) funciona perfeitamente quando o banco de dados do SQL Server não é replicado. Assim que introduzimos a replicação (do SQL Server Standard em um servidor adequado como editor para o SQL Server Express em um laptop como assinante usando a Replicação de mesclagem), começamos a ter uma corrupção estranha do banco de dados que não consigo explicar.

O que acontece é que temos consultas UPDATE que são executadas em várias tabelas no banco de dados, e também temos o próprio Access fazendo operações CRUD em várias tabelas (essa corrupção não se limita a uma tabela). O resultado que vemos é que aleatoriamente (cerca de 1 em 10 operações) uma linha diferente daquela que queríamos atualizar está sendo atualizada, o que substitui os dados que não queríamos substituir.

A replicação, quando configurada, é executada sob demanda no laptop como um pull merge, e a corrupção ocorre independentemente de a replicação ser executada. Ele só precisa ser habilitado. Nenhuma corrupção parece ocorrer quando a replicação não está habilitada.

Não estou acusando a Microsoft de qualquer falha aqui - é totalmente provável que eu tenha esquecido de marcar alguma caixa para evitar isso. Só não tenho certeza do que preciso procurar.

Edit: O que quero dizer com corrupção é o seguinte: Digamos que eu tenha linhas:

ID | FirstName | LastName
--------------------------
1  | John      | Smith
2  | Emma      | Citizen
3  | Bob       | May

Eu então corro algo ao longo das linhas de:

UPDATE Table SET FirstName = "Test" WHERE ID = 1

E depois que isso acontece eu acabo com isso:

ID | FirstName | LastName
--------------------------
1  | Test      | Smith
2  | Test      | Citizen
3  | Bob       | May

Não há mensagens de erro em nenhuma das tabelas do sistema que lidam com a replicação. A única alteração no esquema é que, quando a replicação é habilitada, ela cria a coluna rowguid.

sql-server replication

1 respostas

  1. Best Answer

    Então, acontece (depois de horas e horas tentando diagnosticar isso) que eu tive um problema causado pela replicação de mesclagem sendo habilitada, mas não o que eu achava que tinha. Para referência futura, aqui está o que estava acontecendo ...

    Eu tinha uma consulta DAO escrita em VBA que se parecia com isso:

    Set rs = CurrentDb.OpenRecordset("tblExample", dbOpenDynaset, dbSeeChanges)
rs.AddNew

rs.FirstName = "John"
rs.LastName = "Citizen"

rs.Update

rs.Move 0, rs.LastModified
txtPrimaryKey.Value = rs!PrimaryKeyID

rs.Close

    O problema era a rs.Move 0, rs.LastModifiedlinha, que se move para a linha atualizada mais recentemente (a que acabou de ser inserida) e, em seguida, a próxima linha recupera a nova chave primária. Isso teve vários problemas:

    • Se dois usuários estivessem inserindo registros exatamente ao mesmo tempo, isso recuperaria a mesma chave primária para ambos os usuários.
    • E, claro, os gatilhos que são executados após uma inserção para fazer a replicação de mesclagem também mudam as coisas (em outras tabelas) e isso retorna novamente uma chave primária para o que a replicação estava fazendo, não o que estávamos fazendo.

    Basicamente, esse código funciona para bancos de dados de usuário único (que é onde ele se originou), mas não funciona para cenários de vários usuários.

    A solução (por enquanto) é algo nesse sentido, recuperando manualmente a linha correta usando todos os valores recém inseridos:

    txtPrimaryKey.Value = DLookup("PrimaryKeyID", "tblExample", "FirstName=""John"" AND LastName=""Citizen""")

    Isso tem outros problemas em potencial (se você tiver duas linhas com exatamente os mesmos dados, provavelmente receberá o ID de chave primária errado), mas nesse caso, para esta tabela, isso não é um problema.

    • 0

relate perguntas