Possíveis problemas:
1 edições simultâneas
Um motivo pode ser que o registro em questão foi aberto em um formulário que você está editando. Se você alterar o registro programaticamente durante sua sessão de edição e depois tentar fechar o formulário (e assim tentar salvar o registro), o acesso diz que o registro foi alterado por outra pessoa (claro que é você, mas o Access não sabe ).
Salve o formulário antes de alterar o registro programaticamente.
No formulário:
'This saves the form's current record
Me.Dirty = False
'Now, make changes to the record programmatically
2 Chave primária ou carimbo de data/hora ausentes
Certifique-se de que a tabela do SQL-Server tenha uma chave primária e uma coluna de carimbo de data/hora.
A coluna de carimbo de data/hora ajuda o Access a determinar se o registro foi editado desde a última seleção. O Access faz isso inspecionando todos os campos, se nenhum carimbo de data/hora estiver disponível. Talvez isto não funcione bem com entradas nulas se não houver uma coluna de carimbo de data/hora (veja Problema de 3 bits nulos ).
O carimbo de data/hora, na verdade, armazena um número de versão de linha e não uma hora.
Não se esqueça de atualizar o link da tabela no acesso após adicionar uma coluna de carimbo de data/hora, caso contrário, o Access não a verá. (Observação:o Assistente de upsizing da Microsoft cria colunas de carimbo de data/hora ao converter tabelas do Access em tabelas do SQL-Server.)
Problema de 3 bits nulos
De acordo com @AlbertD.Kallal, isso pode ser um problema de bits nulos descrito aqui:KB280730 (último instantâneo no WayBackMachine, o artigo original foi excluído). Se você estiver usando campos de bits, defina seu valor padrão para
0 e substitua quaisquer NULLs inseridos antes por 0 . Eu costumo usar um BIT DEFAULT 0 NOT NULL para campos booleanos, pois mais se aproxima da ideia de um booleano. O artigo da KB diz para usar um *.adp em vez de um *.mdb; no entanto, A Microsoft descontinuou o suporte para Access Data Projects (ADP) no Access 2013 .
