(Resolvido) Comparar registro de tabelas

[Fsantana]

OLá sou novo por aqui e estou com o seguinte problema.

Tenho dois bancos de dados em access, onde um tem o nome de orçamento e o outro de Pedidos, a função deles é, primeiro o banco de orçamento serve para cadastrar o cliente e os dados do cliente, esse por sua vez gera o código do cliente e da empresa e o codigo de atendimento. Quando esse cliente faz o pedido e finaliza com a gente seu pedido esse mesmo código e dados do cliente são replicados no banco de pedidos, mas o banco de pedidos, ou seja o código do cliente o numero da ordem e os dados do cliente, mas no banco de dados de pedidos nem todos os campos são iguais aos de orçamento somente esses com alguns dados do cliente.

Meu problema é eu gostaria de poder comparar os dois bancos e obter o seguinte resultado o que tivesse igual nos dois bancos fosse mandado para um terceiro banco mas com os dados do banco orçamento, ou seja o orçamento que gerou pedido fosse replicado em um outro banco ou os que não geraram pedido fosse excluidos.

Será que algum dos colegas consegue me ajudar?

[Iceguy]

Pelo que entendi você tem Orçamentos e Pedidos, onde nem todo orçamento é um pedido, mas todo pedido é um orçamento, e você quer a relação de orçamentos que não gererem pedidos, certo?

Assim você busca todos os códigos da tabelaOrcamentos que não existam na tabelaPedidos

SELECT TO.cod
FROM tabelaOrcamentos
WHERE EXISTS (SELECT TP.cod FROM tabelaPedidos AS TP WHERE TO.cod = TP.cod) = FALSE;

[MrMALJ]

Primeira coisa colega seu título de tópico "Ajuda No Access Urgente, Ajuda" é totalmente inadequado tendo em vista que o forum existe para na medida do possivel tentar ajudar os membros, por isso em outros tópicos tente colocar nos títulos algo que represente sua dúvida e não coisas do tipo.

Para fazer a comparação você cria uma consulta com por exemplo os códigos que podem repetir nas respectiva tabelas não sei a nomeclatura ou padronização adotada nos seus bancos então a partir disso compare o que tem eu uma ou noutra, você pode tambem ver o que tem em uma que não existe na outra, para tanto você vai utilizar comando SQL como JOIN, LEFT JOIN, RIGHT JOIN, INNER JOIN e NOT IN para ajudar melhor das duas umas ou você disponibiliza o banco para que alguém faça comparação utilizando a sua estrutura ou você detalhae ambas estruturas. É claro que em qualque uma das duas você terá que dizer quais campos você vai comparar para gerar o terceiro banco.

[Iceguy]

Não querendo me intrometer no projeto dos outros, mas você tem muita redundância de dados, não tem?

Tente criar algo mais enxuto para ganhar e espaço para armazenamento e velocidade nas operações.

Seria algo como

tClientes contendo um código e as informações dos clientes

tProdutos contendo informações dos produtor e serviços

tOrcamento contendo informações exclusivas do orçamento, como datas, codCliente, etc

tItensOrcados contendo os itens orçados, que seria codOrcamento, codProduto, qtdeProduto, e coisas do tipo

E quando fosse gerar um pedido, teria um botão ou algo do tipo "Gerar Pedido" que faria assim

tPedidos tabela com um código, codOrcamento, dtEntrega, etc, etc... Infos de um pedido em si

Fica melhor porque você não tem redundância de dados, não grava na tabela cliente "João da Silva, tabela orcamento "João da Silva", tabela pedido "João da Silva", tabela nota fiscal "João da Silva", tabela contas a receber "João da Silva". Grava na tabela cliente "João da Silva", faz um link do orçamento ao cliente pelo código, do pedido ao orçaento, etc... E quando quiser acessar os dados do cliente lá na frente na nota fiscal, você vai usando JOINs e abre várias tabelas ao invés de abrir a "Tabela Mãe" com muito mais dados para buscar

É claro que em algumas vezes compensa redundância em prol do desempenho, mas isso pra sistemas grandes, que imagino que não seja o caso de quem opte pelo M$ Access

[Fsantana]

Obrigado pela dica moderador, no proximo tópico vou colocar diferente, referente a mandar o banco para ser feito não dá porque é muito grande tem muitos registros e não daria para mandar os campos dos dois bancos são:

tabela orçamento: código - datacad - BV - descrimina - ObsProduto - PEnt - Valprop - condpag - Obs - Frete - Msg - Fornecimento - IPI - códigoAte - CódigoCli

Tabela Pedido:Código - codigoorc - codigocli - codigoate - datacad - faturadoPara - ordemcompra - cliente - bv - Over - ObsProduto - Obsesxpedição - caminhoArte - DataAprovacao - status - CodFat

Onde os campos replicados são tabela orçameto o campo código corresponde ao campo codigo da tabela pedido, e tambem datacad,codigoAte, BV, codigocli.

O campo para critério de busca e comparação para ver se existe pedido gerado é o de código em ambas as tabelas mas precisava que ele me mostrasse a terceira tabela com os campos de orçamento mas só os que realmente tenham gerado pedido ou seja os que existam nas duas tabelas.

desde Já obrigado!!

[Iceguy]

Assim você traz só os orçamentos que NÃO geraram pedidos

SELECT TO.[código]
FROM [tabela orçamento] AS TO
WHERE EXISTS (SELECT TP.codigoorc FROM [Tabela Pedido] AS TP WHERE TO.[código] = TP.codigoorc) = FALSE;

Se quiser os que geraram pedidos não é só buscar todos os pedidos? Ou existe pedido sem orçamento? Se existir pedido sem orçamento troque o FALSE por TRUE

[Fsantana]

Assim você traz só os orçamentos que NÃO geraram pedidos

CODE

SELECT TO.[código]

FROM [tabela orçamento] AS TO

WHERE EXISTS (SELECT TP.codigoorc FROM [Tabela Pedido] AS TP WHERE TO.[código] = TP.codigoorc) = FALSE;

Se quiser os que geraram pedidos não é só buscar todos os pedidos? Ou existe pedido sem orçamento? Se existir pedido sem orçamento troque o FALSE por TRUE

Amigo fiz td certinho gerei a consulta e até alterei alguns campos para exibição, mas só que ele duplica os registros ou seja de 4000 e poucos registros, foi para 11000 e poucos registros, a mesma coisa para exibir só os que não geraram pedido, eu preciso buscar mesmo na tabela de orçamento por q tem campos com informações que só tem lá o de pedidos é só referencia para saber quem gerou ou não pedido.

Editado Março 4, 2011 por Fsantana

[MrMALJ]

Fera está retornando os resultados esperados só que está havendo um problema de cardinalidade, a opção mas simples para resolver isso é você agrupar os resultados, algo mas ou menos assim:

SELECT TO.[código]

FROM [tabela orçamento] AS TO

WHERE EXISTS (SELECT TP.codigoorc FROM [Tabela Pedido] AS TP WHERE TO.[código] = TP.codigoorc) = FALSE group by TO.[código];

[Humm]

Não querendo me intrometer no projeto dos outros, mas você tem muita redundância de dados, não tem?

Tente criar algo mais enxuto para ganhar e espaço para armazenamento e velocidade nas operações.

Seria algo como

tClientes contendo um código e as informações dos clientes

tProdutos contendo informações dos produtor e serviços

tOrcamento contendo informações exclusivas do orçamento, como datas, codCliente, etc

tItensOrcados contendo os itens orçados, que seria codOrcamento, codProduto, qtdeProduto, e coisas do tipo

E quando fosse gerar um pedido, teria um botão ou algo do tipo "Gerar Pedido" que faria assim

tPedidos tabela com um código, codOrcamento, dtEntrega, etc, etc... Infos de um pedido em si

Fica melhor porque você não tem redundância de dados, não grava na tabela cliente "João da Silva, tabela orcamento "João da Silva", tabela pedido "João da Silva", tabela nota fiscal "João da Silva", tabela contas a receber "João da Silva". Grava na tabela cliente "João da Silva", faz um link do orçamento ao cliente pelo código, do pedido ao orçaento, etc... E quando quiser acessar os dados do cliente lá na frente na nota fiscal, você vai usando JOINs e abre várias tabelas ao invés de abrir a "Tabela Mãe" com muito mais dados para buscar

É claro que em algumas vezes compensa redundância em prol do desempenho, mas isso pra sistemas grandes, que imagino que não seja o caso de quem opte pelo M$ Access

tambem concordo..

antes de mais nada ao se criar um sistema, tem q separar o que são dados e o q é informação, pois são coisas absolutamente diferentes.

nas tabelas apenas armazenamos dados.. e muito raramente faze-se necessario armazenar informação, pra efeito de dinamizar o processamento dos dados.. como se fossem resumos.

o sistema do amigo autor do tópico tem muitos dados redundantes.. ou seja, os mesmos dados em varias tabelas diferentes.

o problema de se ter dados redundantes é que perde-se a credibilidade dos mesmos.. uma hora você não vai saber qual tabela tem os dados corretos.

alias se você parar pra analizar, poderia usar apenas uma tabela nisso tudo.. sendo que.. voce começa no orçamento..

no mesmo registro teriam os dados de pedido, caso o orçamento seguisse esse rumo. ficaria tudo sempre preso ao mesmo registro mestre da tabela, isso economiza tempo, processamento e espaço.

no começo a gente n sente o quanto pesa informacoes redundantes.. mas depois q você tem muitos dados pra processar.. ai sim você ve o erro cometido no inicio do projeto

[Fsantana]

Finalizado com sucesso obrigado a todos os colegas que ajudaram.