Como você recebe Mobilink às tabelas Sincronizar para que a mais recente tabela atualizada não é substituído?

Question

Aqui está o cenário. Eu tenho uma base de dados consolidada Oracle. Eu estou usando Mobilink para sincronizar o Oracle com um banco de dados SqlAnywere que está sendo usado em um handheld. Se userA muda um registro no DB remoto no seu dispositivo portátil para "atualizados primeiro" e, em seguida, 10 minutos mais tarde atualizações userB o mesmo registro em seu dispositivo portátil para "atualizados segundo" Quero que o banco de dados consolidado para sempre mostrar "atualizados segundo" depois os dois dispositivos estão sincronizados. Atualmente, se userB sincroniza antes userA a base de dados consolidada lerá "atualizados em primeiro lugar".

Answer 1

Agora, você está usando a resolução de conflitos padrão no MobiLink Server, assim como padrão a última sincronia nas vitórias. Você precisará implementar seu próprio esquema de resolução de conflitos para lidar com isso.

Isso vai exigir duas coisas a acontecer ao banco de dados remoto:

1) Não precisa ser uma coluna na tabela no banco de dados remoto que é sincronizado com o banco de dados consolidada que controla o tempo que os registros foram atualizados no site remoto.

2) Você terá que confiar no relógio do sistema nos locais remotos. As pessoas devem descobrir como os conflitos estão sendo resolvidos e eles querem ter certeza de seus dados vence o conflito, não há nada que impeça um usuário de alterar a hora do sistema em seu dispositivo remoto para a próxima semana, atualizando seus dados, alterando a parte de trás ea hora do sistema em seguida, a sincronização.

No consolidado, você vai precisar para implementar a resolução de conflitos, que não é tão difícil. Enquanto a tabela não inclui quaisquer bolhas, você pode escrever seu resolução de conflitos no caso upload_update para a tabela. Vamos supor que uma mesa no banco de dados remoto que se parece com:

create table Admin (
  admin_id           bigint default global autoincrement(1000000) primary key,
  data               varchar(64) not null,
  rem_last_modified  timestamp not null default timestamp
);

Let também supor uma mesa no consolidado que a aparência muito semelhante, mas também tem uma outra coluna da última modificação para controlar quando as linhas mudaram no consolidado.

create table Admin (
  admin_id           bigint default global autoincrement(1000000) primary key,
  data               varchar(64) not null ,
  rem_last_modified  timestamp not null default ‘1900-01-01’,
  cons_last_modified timestamp default timestamp
);

Normalmente, o evento upload_update seria algo parecido com isto:

call ml_add_table_script( 'v1', 'Admin', 'upload_update',
'update Admin set data = {ml r.data}, 
              rem_last_modified = {ml r.rem_last_modified}  
 where admin_id = {ml r.admin_id}'
);

Em vez disso, vamos re-escrever seu evento upload_update para chamar um procedimento armazenado e também passar nos velhos valores de linha a partir do banco de dados remoto.

call ml_add_table_script( 'v1', 'Admin', 'upload_update',
'call admin_upload_update( {ml r.admin_id}, 
    {ml r.data}, {ml r.rem_last_modified}, 
    {ml o.data}, {ml o.rem_last_modified}’
);

A chave para seu procedimento armazenado é que nós vamos fazer uma atualização, mas a cláusula WHERE da atualização incluirá os valores de chave primária e os antigos valores de linha de base de dados remota. Se alguém mudou a linha no consoliated, esta atualização irá atualizar zero linhas, e sabemos que ocorre um conflito. Se ele atualiza uma linha, em seguida, não houve conflito. Seu procedimento armazenado será algo parecido com isso (pseudo-SQL abaixo):

create procedure admin_upload_update ( 
    @admin_id bigint, 
    @new_data varchar(64), 
    @new_rem_lmod timestamp,
    @old_data varchar(64), 
    @old_rem_lmod timestamp 
)
begin
    declare @cur_rem_lmod timestamp;
    update admin set data = @new_data, rem_last_modified = @new_rem_lmod
     where admin_id = @admin_id 
       and data = @old_data 
       and rem_last_modified = @old_rem_lmod;
    if @@rowcount = 0 then
        // conflict !!
        select rem_last_modified into @cur_rem_lmod 
          from admin where admin_id = @admin_id;
        if @new_rem_lmod > @cur_rem_lmod then
            // update using new_data and new_rem_lmod
        else 
            // do nothing, current values in cons wins
        end if;
    end if;  
end;

Para mais informações sobre a resolução de conflitos, consulte a secção seguinte dos docs v10:

MobiLink - Servidor de Administração

técnicas de sincronização

Manejo de conflitos

http://dcx.sybase.com/index.php#http%3A%2F%2Fdcx.sybase.com%2Fhtml%2Fdbmlen10%2Fml-conflicts-synch.html

Answer 2

Supondo que você tenha implementado de downloads baseado em timestamp ou downloads instantâneos, em seguida, o controle remoto será atualizado para coincidir com o consolidado, se o consolidado foi atualizado por outro remoto desde a última sincronização.

BTW, o tipo de resolução de conflitos que você quer está disponível se você configurar um modelo de sincronização ( http://dcx.sybase.com/index.php#http%3A%2F%2Fdcx.sybase. cOM% 2Fhtml% 2Fdbmgen10% 2Fmg-mg-sobre-s-5060632a.html ), disponível na versão 10 e acima. Ou no assistente Criar Sincronização Modelo, ou na página de mapeamentos depois que o modelo é criado, você pode escolher se quer baseada em linha ou de detecção de conflito baseada em colunas, e diferentes tipos de resolução de conflitos. O que você quer corresponde à opção "timestamp" resolução de conflitos, onde você escolhe uma coluna timestamp existente.

FYI, o assistente explica as opções mais do que a página Mapeamentos, então eu recomendo explorar essas opções no assistente em primeiro lugar. Note-se que se as "vitórias mais recentes, utilizando uma coluna timestamp que você mantenha" opção está cinza, isso significa que não há nenhuma coluna timestamp na tabela sincronizado (s).

Depois de criar um modelo, você pode visualizar os scripts gerados na página Eventos. Quando você tem configuração terminou o modelo, de implantá-lo para criar arquivos SQL e em lote e / ou aplicar SQL diretamente para os bancos de dados.