Come si ottiene Mobilink per sincronizzare le tabelle in modo che il più recente tabella aggiornata non viene sovrascritto?

Question

Ecco lo scenario. Ho un database consolidato Oracle. Sto usando Mobilink per la sincronizzazione con un database Oracle SqlAnywere che viene utilizzato su un palmare. Se userA cambia un record nella remota DB sul proprio dispositivo palmare per "aggiornato prima" e poi 10 minuti più tardi userB aggiorna lo stesso record sul proprio dispositivo palmare per "aggiornato secondo" Voglio che il database consolidato per sempre spettacolo "aggiornato secondo" dopo i due dispositivi sono sincronizzati. Attualmente se userB sincronizza prima userA il database consolidato sarà "aggiornato prima".

Answer 1

In questo momento, si sta utilizzando la risoluzione dei conflitti di default nel MobiLink Server, in modo di default l'ultima sincronizzazione nelle vittorie. Avrai bisogno di implementare il proprio schema di risoluzione dei conflitti per gestire questa situazione.

Ciò richiederà due cose a succedere al database remoto:

1) Non ci sarà bisogno di essere una colonna della tabella al database remoto che sincronizza al database consolidato che tiene traccia del tempo che i record sono stati aggiornati nel sito remoto.

2) Si dovrà fidarsi l'orologio di sistema nei siti remoti. La gente dovrebbe capire come i conflitti vengono risolti e vogliono assicurarsi che i loro dati vince il conflitto, non c'è nulla di fermare un utente di modificare l'ora del sistema sul proprio dispositivo remoto per la prossima settimana, l'aggiornamento dei propri dati, la modifica del tempo di sistema di back e quindi la sincronizzazione.

Al consolidata, è necessario implementare la risoluzione dei conflitti, che non è così difficile. Fino a quando la tabella non include alcun blob, è possibile scrivere la risoluzione dei conflitti in caso upload_update per la tavola. Supponiamo che un tavolo al database remoto che appare come:

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
);

Supponiamo anche un tavolo consolidato che sembra molto simile, ma ha anche un altro ultima colonna modificata per monitorare quando le righe sono cambiate consolidato.

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
);

In genere, il vostro evento upload_update sarebbe simile a questa:

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}'
);

Al contrario, ci ri-scrittura il vostro evento upload_update per chiamare una stored procedure e passare anche nei vecchi valori di riga dal database 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}’
);

La chiave per la stored procedure è che ci accingiamo a fare un aggiornamento, ma la clausola WHERE della aggiornamento includerà sia i valori chiave primaria e gli antichi valori di riga dal database remoto. Se qualcuno ha cambiato la riga al consoliated, questo aggiornamento aggiornerà zero righe, e sappiamo si verifica un conflitto. Se si aggiorna una riga, poi c'è stato alcun conflitto. Il tuo stored procedure sarà simile a questa (pseudo-SQL sottostante):

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;

Per ulteriori informazioni sulla risoluzione dei conflitti, vedere la seguente sezione dei documenti V10:

MobiLink - Administration Server

tecniche di sincronizzazione

conflitti manipolazione

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

Answer 2

Supponendo di aver implementato download basato sul timestamp o download di snapshot, poi il telecomando sarà aggiornato in base al consolidato, se l'consolidata è stata aggiornata da un altro telecomando dopo l'ultima sincronizzazione.

A proposito, il tipo di risoluzione dei conflitti che si desidera è disponibile se si imposta un modello di sincronizzazione ( http://dcx.sybase.com/index.php#http%3A%2F%2Fdcx.sybase. com% 2Fhtml% 2Fdbmgen10% 2Fmg-mg-about-s-5060632a.html ), disponibile in versione 10 e superiori. Sia nella procedura guidata Crea sincronizzazione Modello, o nella pagina Mapping dopo la creazione del modello, è possibile scegliere se si desidera tipi di risoluzione dei conflitti basata su file o di rilevamento dei conflitti basata su colonne, e diverse. Che cosa si vuole corrisponde all'opzione di risoluzione dei conflitti "timestamp", in cui si sceglie una colonna timestamp esistente.

Cordiali saluti, la procedura guidata spiega le opzioni più che nella pagina Mapping, quindi vi consiglio di esplorare quelle opzioni nella procedura guidata prima. Si noti che se le "vittorie recenti, utilizzando una colonna timestamp di mantenere" l'opzione è in grigio, significa che non v'è alcuna colonna timestamp nella tabella sincronizzato (s).

Una volta creato un modello, è possibile visualizzare in anteprima gli script generati nella pagina Eventi. Una volta terminata la creazione del modello, si distribuisce esso per creare file SQL e batch e / o applicare SQL direttamente ai database.