Karakatoa disse:
... Como o timestamp que do registo que vinha do servidor nao tinha significado no lado do cliente, este campo ficava a NULL
Então como saber quais os registos a retirar do servidor por parte do cliente?!?!?! Não havia nenhum tipo de referência??! Pensei que o cliente enviasse o ultimo timestamp retirado do servidor para que o servidor retornasse todos os registos posteriores a essa referência!...
Karakatoa disse:
De notar que no nosso caso, por uma questão de histórico, não se fazia delete a nenhum registo, os registos eram desactivados, nunca removidos. Se pretenderes que ele possa ser removido o cliente nao pode fazer o delete directamente porque depois não consegues informar o servidor da remoção do registo, deves sim, marcar o registo como "Para apagar" e fazeres o delete depois da confirmação do servidor (Nota: Usamos transacções distribuidas nestas operações)
Exactamente, faz todo o sentido. Mas se tiveres mais do que um cliente como é que fazes?!?!
Ex:
-> Cliente1 retira registo do Servidor para máquina local
-> Cliente2 retira registo do Servidor para máquina local
-> Cliente1 marca registo como "Para Apagar"
-> Cliente1 comunica a intensão de apagar registo ao Servidor
-> Servidor apaga registo e re-envia a confirmação ao Cliente1
-> Cliente1 apaga registo na máquina local
-> Cliente2 altera o registo mais um segundo registo com base nessa primeira alteração
-> Cliente2 comunica alterações com o Servidor
-> Servidor não faz P*** de ideia do que fazer com aquilo, pois os dados a alterar não existem...
O problema é mesmo a sincronização, e não própriamente a transacção entre duas bases de dados.
A mesma questão se pode pôr, se os dados podem ser processados quer no Servidor quer no Cliente. Este último pode estar a processar dados que já não existem no lado do Servidor, o que pode ser muito grave.
Karakatoa disse:
Esta solução é a mais simples, mas tem um problema. Uma vez que a exportação pode ser interactiva e é feita num contexto transaccional, bloquia a base de dados... (No nosso caso isso nao era problema uma vez que o acesso era controlado e espaçado no tempo). Para mitigares esse problema podes optar pela estratégia do "pedido de alteração" mas isso é bem mais complicado...
Como assim "pedido da alteração"?!?!?
Karakatoa disse:
Não sei se respondi as tuas questões, este é um assunto que tem pano para mangas...
já agora, o SGBD do cliente era SQLServer enquanto que o do servidor era Informix. Se ambos fosses SQLServer teria estudado a possíbilidade de utilizar as suas funcionalidades de Replicação.
A ideia inicial que tive (quando comecei a pensar nisto) era tentar sincronizar dados de duas bases de dados localizadas remotamente usando para isso XML por exemplo, logo os DBMS's não seriam relevantes pois os acessos aos mesmos não seriam directos... Mas a sincronização não seria em tempo real, ex:
Se duas filiais quiserem comunicar com a sede fazendo o update da informação diária, usariam uma tarefa agendada para determinada hora com menos concorrência (internet/postos trabalho). O grande problema, é fazer coincidir o trabalho das três areas geográficas numa só base de dados (sede)...