Fórum Copiar registros de um DB para outro no em tempo de execução #395940

18/02/2011

0

Bom, tenho 2 DB's com a mesma estrutura, sendo que 1 é o "Central" e o outro apenas uma copia. O que ocorre é que esta copia sofre modificações (inserções, delete, e outros) e preciso que o DB central receba todas essas modificações. Utilizo DBexpress , delphi 2010

Como faço isso ?
Ronaldo Lanhellas

Ronaldo Lanhellas

Responder

Posts

18/02/2011

Rogerio

Qual é o banco de dados que você utiliza?   Procure algo sobre replicação de banco de dados   Qualquer coisa volte a postar!     Boa Sorte!
Responder

Gostei + 0

18/02/2011

Ronaldo Lanhellas


  utilizo firebird ! e sinceramente não tenho ideia de como copiar apenas os registros alterados para outro banco (Central) em tempo de execução
Responder

Gostei + 0

18/02/2011

Marco Salles

Amigo , todas as Alteraçoes estão no Delta.. Sed vc que somente as Alteraçoes então Faça   CdsArmazenarAlteracoes.Data:=CdsQueSofreraAlteracoes.Delta;   Depois é so Comitar para O banco   CdsArmazenarAlteracoes.ApplayUpdates;        
Responder

Gostei + 0

19/02/2011

Ronaldo Lanhellas


  mais amigo, pense comigo ! eu tenho 2 bd's sendo que 1 desses é o central, já o local que fica na maquina (notebook) do cara, ele vai ficar quase 1 semana fazendo alterações nele sem passar nada pro central. depois dessa semana ele tem que transferir todas as modificações para o central, axo que não tem como ficar salvando no delta durante 1 semana né ? nem em xml pois vai ficar pesadão :D
Responder

Gostei + 0

19/02/2011

Marco Salles

  Vou imaginar que vc esta tentando utilizar esta arquitetura   https://www.devmedia.com.br/forum/viewtopic.asp?id=395106     e vou simular uma possivel situação :   Imagine que vc viage por ai Cadastrando as cidades do Mundo (Vc trabalha para o IBGE).. Vc tem que trabalhar desconectado   Vai começar do Zero   Vamos supor que vc cadastre 10000 cidades por mes   a cada dia vc Cadastra 400 Cidade   Qnd vc der um SaveToFile , vc ira salvar 400 cidades No dia seguinte vc carregara 400 cidades , salvar mais 400 cidades e dara um Savetofile de 800 cidades Carregara mais 800 cidades enfim , parte do principio que o processo tende a ser tornar moroso   De fato vc pode ter razão , mas tb não ..   Vc ja testou , qnt tempo leva um ClientDataSet para carregar 10000 dados e salvar ???? eu confesso quu não , mas acredito que deva ser rápido   Faça um Teste Simples ::::  
uses
MMSystem;
var
  StartTick, EndTick: DWord;
  Para Gerar resultou em 4455 milesegundos   // so para gerar os Dez Mil Registros
procedure TForm1.btnGerarClick(Sender: TObject);
var
  i: Integer;
begin
 StartTick:=TimeGetTime;
for i := 0 to  10000 do
  begin
    cds.Append;
    cds.FieldByName('nome').AsString:='Marco'+Inttostr(i);
    cds.FieldByName('Idade').AsInteger:=i;
    cds.Post;
  end;
 EndTick := TimeGetTime;
self.Caption:='Duration (in milliseconds) '+inttostr( EndTick - StartTick);
end;
    Para Gravar 21 milesegundos  
procedure TForm1.btsSalvarClick(Sender: TObject);
begin
 StartTick:=TimeGetTime;
cds.SaveToFile('tempCds.xml',dfXMLUTF8);
 EndTick := TimeGetTime;
self.Caption:='Duration (in milliseconds) '+inttostr( EndTick - StartTick);
end;
  Para ler  26 milesegundos  
procedure TForm1.BtnCarregarClick(Sender: TObject);
begin
 StartTick:=TimeGetTime;
cds.LoadFromFile('tempCds.xml');
 EndTick := TimeGetTime;
self.Caption:='Duration (in milliseconds) '+inttostr( EndTick - StartTick);
end;
  É para se Preocupar com Isto ???????  E olhe que meu PC é bonzinho....
Responder

Gostei + 0

19/02/2011

Ronaldo Lanhellas


  otimo, entendi. vou usar xml mesmo agora veja se meu conceito esta certo, com base na estrutura que voce pegou la do topico anterior que é a mesma

1 - Quando usuario logar pela primeira vez, obrigatoriamente ele tem que estar conectado ao banco de dados central onde tem todas as tabelas e dados originais.
2 - Já logado, ele aperta em um botão "SINCRONIZAR DO SERVIDOR PARA CLIENTE", e todas as tabelas e registros do banco central vão para a maquina do cliente em formato XML.
3 - Ae o cliente vai emborar com o notebook cadastrar cidades (como voce disse no exemplo),  sendo que ele só tem os xml no notebook.
4 - Ao abrir o programa pela segunda vez (agora está desconectado do banco central), ele já carrega todos os ClientDataSet pelos XML.
5 - Agora vem a sacada, pois só interessa as alterações feitas, o que não foi mudado pode continuar como estava. Então quando o cliente cadastrar uma nova cidade automaticamente ele já salvar o delta do clientdataset em um outro XML chamado por exemplo: cidadesAlteradas.xml
Eu teria que fazer isso, pois quando voltar ao banco central e copiar todos os dados do XML para o banco, eu não posso de forma alguma sobreescrever os que já estão lá, apenas incluir os novos, ou alterar os que o cliente mudou. 


Ta certo meu pensamento ? Lembrando que tenho que salvar no banco central só os dados alterados
Responder

Gostei + 0

19/02/2011

Marco Salles


  otimo, entendi. vou usar xml mesmo agora veja se meu conceito esta certo, com base na estrutura que voce pegou la do topico anterior que é a mesma
Isto  
1 - Quando usuario logar pela primeira vez, obrigatoriamente ele tem que estar conectado ao banco de dados central onde tem todas as tabelas e dados originais.
Sim , vc faz um cds.Open e depois um Cds.close ( Lembra do KeepConnection)
2 - Já logado, ele aperta em um botão "SINCRONIZAR DO SERVIDOR PARA CLIENTE", e todas as tabelas e registros do banco central vão para a maquina do cliente em formato XML.
É um CDS.OPEN pode Dar Um CDS.CLOSE e depois Um Cds.SaveTofile
3 - Ae o cliente vai emborar com o notebook cadastrar cidades (como voce disse no exemplo),  sendo que ele só tem os xml no notebook.
Foi embora ...
4 - Ao abrir o programa pela segunda vez (agora está desconectado do banco central), ele já carrega todos os ClientDataSet pelos XML.
Isto ..Ao dar  Um CDS.LoadFormFile
 
5 - Agora vem a sacada, pois só interessa as alterações feitas, o que não foi mudado pode continuar como estava. Então quando o cliente cadastrar uma nova cidade automaticamente ele já salvar o delta do clientdataset em um outro XML chamado por exemplo: cidadesAlteradas.xml
  Não ... No mesmo XML anterior .. Ele ira Sobrescrever o Anterior com as Novas Modificaçoes . O Midas faz isto para Vc . Ele controla internamente e muito bem diga-se de passagem o que é edição , inserção , exclusão Um mesmo Xml , desde do momento que o Vendedor saiu ate ele voltar . Vc pode armazenar em copias de segurança , fazer BeacKup enfim é apenas um arquivo de texto . Que na hora certa vc carrega para o CDS e Aplica na Base de Dados   Qnd o clientDataSet faz a primeira Conexao , No Xml dele num local especifico o Delta estar vazio Qnd vai inserindo , editando , excluindo , ( o Delta no mesmo XML daquele SaveToFile que vc fez a primeira Vez ) Vai sendo Modificado .. Mas so em uma Determinada Região .. ( em palavras não técnicas é claro ) Qundo vc da um ApplayUpdates o Delta do mesmo Xml vai ser Limpo , dizendo : Hora não tem mais nenhuma Atualização ... > Nesta Hora vc tem que sobrescrever o XML que esta no NoteBook do Vendedor . Vc tem que limpar este Xml , atraves novamente de um SaveToFile
Eu teria que fazer isso, pois quando voltar ao banco central e copiar todos os dados do XML para o banco, eu não posso de forma alguma sobreescrever os que já estão lá, apenas incluir os novos, ou alterar os que o cliente mudou. 
  Mas desta forma vc não sobrescreve. O Maior perigo aqui é vc sobrescrever o XML do Vendedor fazendo uma operação indevida , por erro seu . Mas não pelo erro do Delphi  
Ta certo meu pensamento ? Lembrando que tenho que salvar no banco central só os dados alterados
  Ta mais ou menos certo . Detalhes deverão ser particulares a sua arquitetura Um dele por exemplo .. Preciso carregar tudo para o Cds do Vendedor ???? Vamos supor que vc tem coisas do ano Retrassado .. Não vai interressar , mas é necessário do ano passado Então qnd vc der um cds.OPen ( a instrução sql passada deve conter um WHERE para Limitar este Tempo ) O Seu XML fica Menor ainda ... Depois é so fazer a Atualização ( Não tem Problema se o XML do CDS esta Menor do que os Dados Naturais ) Por exemplo .. Sua Base de Dados Cem Mil Registro So interressa do Ano passado para cá Total DEZ MIL Registro porque vc faz um WHERE O Vendedor sai Vende mais Mil Items Applica Vai dar Problema porque a Base de Ddos tem CEM Mil e o XML do CDS tem ONZE mil Registro assim Distribuidos (DEZ MIL Na estrutura de Dados , UM MIL Na estrutura do Delta no Mesmo XML ) ???? Vai dar problema Resposta) Não .. Ele so vai olhar para os Mil Regitros a serem atualizados   Conclusão Eu usei aqui uma Linguagem nen NADA técnica . Me perdõem os mais puristas . A linguagem foi utilizada  para tentar passar o conceito e não as definiçoes .. OK
Responder

Gostei + 0

19/02/2011

Ronaldo Lanhellas

mais tem um probleminha nisso, veja só :
vamos supor que no banco central o administrador modificou um registro lá ! 
Sendo que o vendedor que saiu para vender já tinha pego os arquivos xml e agora estão desatualizados , já que o administrador modificou este registro. Quando o vendedor voltar e sincronizar com o servidor, os xml vão ser copiados para o banco central mais não podem sobreescrever essa modificação que foi feita pelo administrador com a antiga que esta no xml.
e agora ?
Responder

Gostei + 0

19/02/2011

Marco Salles

mais tem um probleminha nisso, veja só :
vamos supor que no banco central o administrador modificou um registro lá ! 
Sendo que o vendedor que saiu para vender já tinha pego os arquivos xml e agora estão desatualizados , já que o administrador modificou este registro. Quando o vendedor voltar e sincronizar com o servidor, os xml vão ser copiados para o banco central mais não podem sobreescrever essa modificação que foi feita pelo administrador com a antiga que esta no xml.
e agora ?
  Não entendi.. Não PODEM ou não DEVEM ??? O que vc quer dizer   Não poder da um sentido Tecnico . Não Devem dá um sentido de Hierarquia   qual o sentido que vc se refere ??   Tecnico se resolve com o Delphi   Problema de Hierarquia é algo pessoal . Analise de caso a caso .        
Responder

Gostei + 0

19/02/2011

Ronaldo Lanhellas

  bom consegui resolver meu problema em partes, mais assim !

Eu quero ficar salvando apenas o delta dentro do XML, consegui salvar o primeiro, mais ae se eu salvar outro delta (modificação), simplesmente ele sobreescreve todo o arquivo xml, e não quero isso porque eu quero depois pegar essas modificações e jogar do db.
Responder

Gostei + 0

19/02/2011

Ronaldo Lanhellas

na verdade  o que eu preciso é só ficar salvando todas as alterações no XML, ae quando o vendedor voltar só carrega no banco central e fim de papo :D
fiz assim

var  cdsDelta: TClientDataSet;begin  cdsDelta := TClientDataSet.Create(Self);  cdsDelta.Data := TClientDataSet(Sender).Delta;  cdsDelta.SaveToFile('D:\CDSPRODUTO.XML', dfXML);  cdsDelta.Free;end;

mais toda vez que salva ele sobreescreve a antiga... 
por exemplo se eu inserir um registro novo, ele refaz todo o xml só com este novo registro e não quero isso
Responder

Gostei + 0

19/02/2011

Ronaldo Lanhellas

bom, acho que descobri uma forma bem eficiente, só não sei como fazer :D
posso usar um banco central, e varios bancos locais (um por notebook obviamente)
o vendedor vai fazendo as modificações no banco local, ae quado for sincronizar , uma rotina verifica (compara) o banco central com o local, se ouver algo diferente, ele muda no central
agora como fazer? :d
Responder

Gostei + 0

19/02/2011

Marco Salles

bom, acho que descobri uma forma bem eficiente, só não sei como fazer :D
posso usar um banco central, e varios bancos locais (um por notebook obviamente)
o vendedor vai fazendo as modificações no banco local, ae quado for sincronizar , uma rotina verifica (compara) o banco central com o local, se ouver algo diferente, ele muda no central
agora como fazer? :d
é realmente ; É muito eficiente esta forma ..
Responder

Gostei + 0

19/02/2011

Ronaldo Lanhellas

  foi a melhor que encontrei :D hehehe ...
se tiver alguma sugestão para melhoria eu agradeço ! heheh
Responder

Gostei + 0

16/05/2013

José

Este tópico esta sendo fechado por inatividade. Se necessário, sinalizar para que seja reaberto ou abrir um novo.
Responder

Gostei + 0

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.

Aceitar