ACCESS - MODIFICACAO NA TABELA
Olá!
Amigos, tenho uma tabela gravada(back up) até o dia 30/09.
Gostaria de poder confrontar o que foi modificado. (alterações de dados nos campos, novos registros, exclusão de registro) com uma tabela de hoje, por exemplo.
Tipo: quando eu colocar para confrontar ele poder salvar o registro(modificado, ou adicionado) em outra tabela.
tentei fazer UNION, mas não tive exito.
Alguém tem uma idéia?
T+
Caju
Amigos, tenho uma tabela gravada(back up) até o dia 30/09.
Gostaria de poder confrontar o que foi modificado. (alterações de dados nos campos, novos registros, exclusão de registro) com uma tabela de hoje, por exemplo.
Tipo: quando eu colocar para confrontar ele poder salvar o registro(modificado, ou adicionado) em outra tabela.
tentei fazer UNION, mas não tive exito.
Alguém tem uma idéia?
T+
Caju
Deixa eu ver se entendi, vc tem uma tabela em produção e uma tabela [Ô]histórico[Ô] e vc quer atualizar a tabela histórico com as diferenças da tabela de produção, isso? Se for isso, por favor coloque as estruturas das duas tabelas...
Exemplo: Tabela 1
ID | Nome | Situacao | Valor Inicial | Valor Atual | Valor Final | Data
Tabela2 igual estrutura
ID | Nome | Situacao | Valor Inicial | Valor Atual | Valor Final | Data
sendo que a primeira tem dados de 1 mês atras, por exemplo. e tabela2 são dados mais atuais, com exclusão, adição ou alteração do conteudo da tabela1.
deu para entender melhor?
ID | Nome | Situacao | Valor Inicial | Valor Atual | Valor Final | Data
Tabela2 igual estrutura
ID | Nome | Situacao | Valor Inicial | Valor Atual | Valor Final | Data
sendo que a primeira tem dados de 1 mês atras, por exemplo. e tabela2 são dados mais atuais, com exclusão, adição ou alteração do conteudo da tabela1.
deu para entender melhor?
Os ID[ô]s vão coincidir?
ID são únicos e vão coincidir.
Isso, até onde eu entendi, você quer fazer via SELECT, e não por comparação direta, é isso?
Tente fazer algo como:
Tente fazer algo como:
SELECT
A.ID,
A.NOME,
[ô]Alterado[ô] AS STATUS
FROM [TABELA1] A
INNER JOIN [TABELA2] B ON A.ID=B.ID
WHERE
((A.Nome<>B.Nome) OR
(A.Situacao<>B.Situacao) OR
(A.[Valor Inicial]<>B.[Valor Inicial]) OR
(A.[Valor Atual]<>B.[Valor Atual]) OR
(A.[Valor Final]<>B.[Valor Final]) OR
(A.Data<>B.Data))
UNION
SELECT
A.ID,
A.NOME,
[ô]Inalterado[ô] AS STATUS
FROM [TABELA1] A
INNER JOIN [TABELA2] B ON A.ID=B.ID
WHERE
((A.Nome=B.Nome) AND
(A.Situacao=B.Situacao) AND
(A.[Valor Inicial]=B.[Valor Inicial]) AND
(A.[Valor Atual]=B.[Valor Atual]) AND
(A.[Valor Final]=B.[Valor Final]) AND
(A.Data=B.Data))
acho que é por aÃ!
agora uma dúvida: no exemplo eu coloquei poucos campos, mas na verdade são 147 campos. tenho que digitar de um por um?
agora uma dúvida: no exemplo eu coloquei poucos campos, mas na verdade são 147 campos. tenho que digitar de um por um?
Hehehe, essa é a verdadeira questão.
Bom, se o que você quer é saber se houveram alterações em qualquer um dos campos, terá de especificar um á um.
Esse tipo de situação ocorre eventualmente, não apenas com o MS-Access, mas com qualquer banco, onde por algum problema ocorrido você deve [Ô]restaurar[Ô] um status de uma faixa de tempo. Por exemplo, quando uma base foi restaurada á partir da cópia errada, ou ainda, quando um processo de aplicativo altera indevidamente um grupo de registros, por exemplo.
Se me permitir, vou usar o seu tópico para derivar um pequeno artigo, já que a quantidade de campos me chamou a atenção, ok? Isso pode ser útil para outros usuários do site.
Como o que ocorreu com você não é uma situação infrequente ou incomum, para facilitar os trabalhos de manutenção, e não entenda isso como crÃtica, por favor, é apenas uma orientação de praxe, uma indicação de prática de normatização, procure utilizar sempre estruturas pequenas.
Por exemplo, nesse caso especÃfico, dificilmente um usuário vai requerer 147 informações diferentes ao mesmo tempo. é claro, ele pode exigir até mais informações do que isso sobre um registro, mas não será ao mesmo tempo. Assim, normalmente, a tabela pode ser parcionada em outras menores, com grupos de informações afins.
Normatização (e não normalização, como frequentemente se usa), é o estabelecimento e posterior adoção de regras (normas) á geração de estruturas de dados. Essas regras servem para, dentre outras coisas:
1. - Facilitar a absorção da lógica de fluxo das informações por quaisquer desenvolvedores;
2. - Propiciar melhor desempenho de consultas e procedimentos;
3. - Minimizar o tráfego de informações entre buffers, caches e rede;
4. - Diminuir as probabilidades de pêrda de informações por procedimentos manuais.
Nem sempre a normatização é benéfica ao desempenho, há situações onde a massa de informações dos registros é composta de modo tão fracionado, que ela acaba se tornando inimiga da performance, mas via de regra, e para a maioria dos casos, a normatização é uma aliada poderosa. Assim, é importante observar, sempre que possÃvel, algumas regras gerais, antes da criação de uma estrutura de dados. Basicamente:
- Entidades (tabelas, procedimentos e views) com poucos campos são mais ágeis do que estruturas maiores.
- Tipos impróprios de dados podem diminuir o desempenho de uma entidade e ás vezes restringir suas funcionalidades.
- Se um grupo de informações relativas á uma entidade podem ser visualizadas em separado, então podem compor uma entidade separada, relacionada á primeira.
- Se um conjunto de informações é utilizado com freqüencia em buscas, filtros e ordenações, então devem compôr Ãndices.
Há muitas outras regras e variantes, e sempre se deve ter em mente que cada caso é único.
Havendo interesse da turma, podemos abrir um novo tópico para montar um artigo em conjunto, utilizando uma situação hipotética de criação de base de dados, onde o pessoal possa contribuir e ao mesmo tempo ter uma base de referência.
E novamente, desculpe aproveitar o seu caso como [Ô]gancho[Ô].
Bom, se o que você quer é saber se houveram alterações em qualquer um dos campos, terá de especificar um á um.
Esse tipo de situação ocorre eventualmente, não apenas com o MS-Access, mas com qualquer banco, onde por algum problema ocorrido você deve [Ô]restaurar[Ô] um status de uma faixa de tempo. Por exemplo, quando uma base foi restaurada á partir da cópia errada, ou ainda, quando um processo de aplicativo altera indevidamente um grupo de registros, por exemplo.
Se me permitir, vou usar o seu tópico para derivar um pequeno artigo, já que a quantidade de campos me chamou a atenção, ok? Isso pode ser útil para outros usuários do site.
Como o que ocorreu com você não é uma situação infrequente ou incomum, para facilitar os trabalhos de manutenção, e não entenda isso como crÃtica, por favor, é apenas uma orientação de praxe, uma indicação de prática de normatização, procure utilizar sempre estruturas pequenas.
Por exemplo, nesse caso especÃfico, dificilmente um usuário vai requerer 147 informações diferentes ao mesmo tempo. é claro, ele pode exigir até mais informações do que isso sobre um registro, mas não será ao mesmo tempo. Assim, normalmente, a tabela pode ser parcionada em outras menores, com grupos de informações afins.
Normatização (e não normalização, como frequentemente se usa), é o estabelecimento e posterior adoção de regras (normas) á geração de estruturas de dados. Essas regras servem para, dentre outras coisas:
1. - Facilitar a absorção da lógica de fluxo das informações por quaisquer desenvolvedores;
2. - Propiciar melhor desempenho de consultas e procedimentos;
3. - Minimizar o tráfego de informações entre buffers, caches e rede;
4. - Diminuir as probabilidades de pêrda de informações por procedimentos manuais.
Nem sempre a normatização é benéfica ao desempenho, há situações onde a massa de informações dos registros é composta de modo tão fracionado, que ela acaba se tornando inimiga da performance, mas via de regra, e para a maioria dos casos, a normatização é uma aliada poderosa. Assim, é importante observar, sempre que possÃvel, algumas regras gerais, antes da criação de uma estrutura de dados. Basicamente:
- Entidades (tabelas, procedimentos e views) com poucos campos são mais ágeis do que estruturas maiores.
- Tipos impróprios de dados podem diminuir o desempenho de uma entidade e ás vezes restringir suas funcionalidades.
- Se um grupo de informações relativas á uma entidade podem ser visualizadas em separado, então podem compor uma entidade separada, relacionada á primeira.
- Se um conjunto de informações é utilizado com freqüencia em buscas, filtros e ordenações, então devem compôr Ãndices.
Há muitas outras regras e variantes, e sempre se deve ter em mente que cada caso é único.
Havendo interesse da turma, podemos abrir um novo tópico para montar um artigo em conjunto, utilizando uma situação hipotética de criação de base de dados, onde o pessoal possa contribuir e ao mesmo tempo ter uma base de referência.
E novamente, desculpe aproveitar o seu caso como [Ô]gancho[Ô].
Tópico encerrado , respostas não são mais permitidas