Campos lookup em branco e causando lentidão!!!
Olá
Tenho uma tebela PEDIDOS, que inseri 6 campos lookup (Fornecedor, transp., Nat. operaçao, etc), além da tabela detalhe ITENS que possui mais 1 campo lookup (da descrição do item).
O problema é que fica lento na hora de abrir o form, pois tenho que abrir a tabela PEDIDOS e ITENS (mestre/detalhe com IBDATASET). E mais 6 tabelas (com IBQUERY) que são as tabelas que uso no lookup. Além de quando estou editando ou inserindo, os campos lookup ficam em branco, não mostrando a descrição.
No IBDATASET de PEDIDOS, uso: ´Select * from pedidos where pedido=1´.
Alguém tem alguma sugestão para agilizar na hora de abrir o form e os campos lookup não ficarem em branco?
Até +
Tenho uma tebela PEDIDOS, que inseri 6 campos lookup (Fornecedor, transp., Nat. operaçao, etc), além da tabela detalhe ITENS que possui mais 1 campo lookup (da descrição do item).
O problema é que fica lento na hora de abrir o form, pois tenho que abrir a tabela PEDIDOS e ITENS (mestre/detalhe com IBDATASET). E mais 6 tabelas (com IBQUERY) que são as tabelas que uso no lookup. Além de quando estou editando ou inserindo, os campos lookup ficam em branco, não mostrando a descrição.
No IBDATASET de PEDIDOS, uso: ´Select * from pedidos where pedido=1´.
Alguém tem alguma sugestão para agilizar na hora de abrir o form e os campos lookup não ficarem em branco?
Até +
Ivonei
Curtidas 0
Respostas
Rage_against
09/09/2003
Pra ficar rápido mesmo o certo é não usar campo lookup, ai vc não vai precisar abrir tantas tabelas assim e conserteza um com SQL fica bem mais rapida.
GOSTEI 0
Afarias
09/09/2003
umas dicas:
1 - procure trazer os campos de outras tabelas no seu SELECT com JOINS
2 - para tabelas mais ´estáticas´ (ex: NAT. OPERAÇÃO) procure carregar os valores uma vez para uma tabela em memória (ex: ClientDataSet) para fazer os LOOKUPs.
3 - para as tebelas mais ´dinâmicas´ (e grandes) não faça LOOKUPs, proporcione PESQUISAS para encontrar apenas O registro ou uma PEQUENA quantidade deles.
T+
1 - procure trazer os campos de outras tabelas no seu SELECT com JOINS
2 - para tabelas mais ´estáticas´ (ex: NAT. OPERAÇÃO) procure carregar os valores uma vez para uma tabela em memória (ex: ClientDataSet) para fazer os LOOKUPs.
3 - para as tebelas mais ´dinâmicas´ (e grandes) não faça LOOKUPs, proporcione PESQUISAS para encontrar apenas O registro ou uma PEQUENA quantidade deles.
T+
GOSTEI 0
Ivonei
09/09/2003
Obrigado pela atenção Rage_Against e afarias.
1 - procure trazer os campos de outras tabelas no seu SELECT com JOINS
[color=blue:ac39769df3]R.: Nunca fiz um joi. Vou tentar fazer, mas ficarei grato se voce pudesse exemplificar um ´select com joins´ no lugar dos seis campos lookup.
[/color:ac39769df3]
2 - para tabelas mais ´estáticas´ (ex: NAT. OPERAÇÃO) procure carregar os valores uma vez para uma tabela em memória (ex: ClientDataSet) para fazer os LOOKUPs.
[color=blue:ac39769df3]R.: Estou usando Query para estas tabelas e fazendo lookup. No caso da Nat. Operação, você diz que posso usar Lookup sem problemas?[/color:ac39769df3]
3 - para as tebelas mais ´dinâmicas´ (e grandes) não faça LOOKUPs, proporcione PESQUISAS para encontrar apenas O registro ou uma PEQUENA quantidade deles.
[color=blue:ac39769df3]R.: Não entendi. Se eu quero mostrar o nome do cliente que está num cadastro com 6500 registros, cada vez que inserir um novo item, como fazer esta pesquisa, sem causar lentidão no processo? Não seria melhor usar o join?[/color:ac39769df3]
Abraços
1 - procure trazer os campos de outras tabelas no seu SELECT com JOINS
[color=blue:ac39769df3]R.: Nunca fiz um joi. Vou tentar fazer, mas ficarei grato se voce pudesse exemplificar um ´select com joins´ no lugar dos seis campos lookup.
[/color:ac39769df3]
2 - para tabelas mais ´estáticas´ (ex: NAT. OPERAÇÃO) procure carregar os valores uma vez para uma tabela em memória (ex: ClientDataSet) para fazer os LOOKUPs.
[color=blue:ac39769df3]R.: Estou usando Query para estas tabelas e fazendo lookup. No caso da Nat. Operação, você diz que posso usar Lookup sem problemas?[/color:ac39769df3]
3 - para as tebelas mais ´dinâmicas´ (e grandes) não faça LOOKUPs, proporcione PESQUISAS para encontrar apenas O registro ou uma PEQUENA quantidade deles.
[color=blue:ac39769df3]R.: Não entendi. Se eu quero mostrar o nome do cliente que está num cadastro com 6500 registros, cada vez que inserir um novo item, como fazer esta pesquisa, sem causar lentidão no processo? Não seria melhor usar o join?[/color:ac39769df3]
Abraços
GOSTEI 0
Afarias
09/09/2003
|R.: Nunca fiz um joi. Vou tentar fazer, mas ficarei grato se voce pudesse
|exemplificar um ´select com joins´ no lugar dos seis campos lookup.
Faça o JOIN apenas nas tabelas q não for fazer LOOKUP, ex::
select vendas.data, vendas.cli_cod, clientes.nome
from vendas inner join clientes on (vendas.cli_cod = clientes.cli_cod)
where vendas.numero = 1234;
Existem vários tipos e formas de JOINS, o melhor a fazer é dá uma lida na documentação do INTERBASE.
|R.: Estou usando Query para estas tabelas e fazendo lookup. No caso da
|Nat. Operação, você diz que posso usar Lookup sem problemas?
Sim, (acho) -- já q trata-se de algo ´estático´ ... os usuários normalmente não ficam cadastrando nat. de operação o tempo todo. E, também trata-se de uma tabela pequena (com poucos registros) -- essas são duas qualidades q fazem uma tabela ser ótima para LOOKUP -- vc pode carregar os valores no início da oparação (entrada na tela de vendas por exemplo) ou ainda MELHOR :: carregar os registros para uma ´tabela em memória´ (tipo ClientDataSet) e ficar usando estes registros sem ter que ficar carregando do banco o tempo todo.
|R.: Não entendi. Se eu quero mostrar o nome do cliente que está num
|cadastro com 6500 registros, cada vez que inserir um novo item, como
|fazer esta pesquisa, sem causar lentidão no processo? Não seria melhor
|usar o join?
O JOIN vc vai usar para trazer os registros (SELECT) ... e as pesquisas, quando quizer alterar ou inserir um valor (INSERT, UPDATE).
Exemplo:: vou fazer uma nova venda, então digito o CPF do cliente -- mas eu preciso da CHAVE (CLI_COD) para jogar na tabela de clientes ... então eu pesquiso pelo CPF o CLI_COD do cliente -- e se eu não tiver o CPF ?? então, permito uma consulta por nome (o usuário entra com o primeiro nome e vc pesquisa todos os que começam com ele) ... pronto!!
Assim, durante a venda, vc não precisa carregar os 6500 registros para fazer o LOOKuP ... deve carregar uns poucos de 1 a 20 registros por ex.
T+
|exemplificar um ´select com joins´ no lugar dos seis campos lookup.
Faça o JOIN apenas nas tabelas q não for fazer LOOKUP, ex::
select vendas.data, vendas.cli_cod, clientes.nome
from vendas inner join clientes on (vendas.cli_cod = clientes.cli_cod)
where vendas.numero = 1234;
Existem vários tipos e formas de JOINS, o melhor a fazer é dá uma lida na documentação do INTERBASE.
|R.: Estou usando Query para estas tabelas e fazendo lookup. No caso da
|Nat. Operação, você diz que posso usar Lookup sem problemas?
Sim, (acho) -- já q trata-se de algo ´estático´ ... os usuários normalmente não ficam cadastrando nat. de operação o tempo todo. E, também trata-se de uma tabela pequena (com poucos registros) -- essas são duas qualidades q fazem uma tabela ser ótima para LOOKUP -- vc pode carregar os valores no início da oparação (entrada na tela de vendas por exemplo) ou ainda MELHOR :: carregar os registros para uma ´tabela em memória´ (tipo ClientDataSet) e ficar usando estes registros sem ter que ficar carregando do banco o tempo todo.
|R.: Não entendi. Se eu quero mostrar o nome do cliente que está num
|cadastro com 6500 registros, cada vez que inserir um novo item, como
|fazer esta pesquisa, sem causar lentidão no processo? Não seria melhor
|usar o join?
O JOIN vc vai usar para trazer os registros (SELECT) ... e as pesquisas, quando quizer alterar ou inserir um valor (INSERT, UPDATE).
Exemplo:: vou fazer uma nova venda, então digito o CPF do cliente -- mas eu preciso da CHAVE (CLI_COD) para jogar na tabela de clientes ... então eu pesquiso pelo CPF o CLI_COD do cliente -- e se eu não tiver o CPF ?? então, permito uma consulta por nome (o usuário entra com o primeiro nome e vc pesquisa todos os que começam com ele) ... pronto!!
Assim, durante a venda, vc não precisa carregar os 6500 registros para fazer o LOOKuP ... deve carregar uns poucos de 1 a 20 registros por ex.
T+
GOSTEI 0
Ivonei
09/09/2003
O JOIN vc vai usar para trazer os registros (SELECT) ... e as pesquisas, quando quizer alterar ou inserir um valor (INSERT, UPDATE).
Exemplo:: vou fazer uma nova venda, então digito o CPF do cliente -- mas eu preciso da CHAVE (CLI_COD) para jogar na tabela de clientes ... então eu pesquiso pelo CPF o CLI_COD do cliente -- e se eu não tiver o CPF ?? então, permito uma consulta por nome (o usuário entra com o primeiro nome e vc pesquisa todos os que começam com ele) ... pronto!!
Assim, durante a venda, vc não precisa carregar os 6500 registros para fazer o LOOKuP ... deve carregar uns poucos de 1 a 20 registros por ex.
É que faço assim: Num form de busca, uso ´Cliente.Locate(´CODCLI´,edit1.text,[loPartialKey]);´ para localizar o cliente cfe o usuário vai digitando.
Do seu jeito, pelo que entendi, o usuário digita um nome, clica num botão ´procurar´ para filtrar o nome num ´select com Like´ e só depois escolhe uma das alternativas filtradas. Não seria mais complicado (menos prático)?
Por favor, me corrija se eu estiver errado.
Exemplo:: vou fazer uma nova venda, então digito o CPF do cliente -- mas eu preciso da CHAVE (CLI_COD) para jogar na tabela de clientes ... então eu pesquiso pelo CPF o CLI_COD do cliente -- e se eu não tiver o CPF ?? então, permito uma consulta por nome (o usuário entra com o primeiro nome e vc pesquisa todos os que começam com ele) ... pronto!!
Assim, durante a venda, vc não precisa carregar os 6500 registros para fazer o LOOKuP ... deve carregar uns poucos de 1 a 20 registros por ex.
É que faço assim: Num form de busca, uso ´Cliente.Locate(´CODCLI´,edit1.text,[loPartialKey]);´ para localizar o cliente cfe o usuário vai digitando.
Do seu jeito, pelo que entendi, o usuário digita um nome, clica num botão ´procurar´ para filtrar o nome num ´select com Like´ e só depois escolhe uma das alternativas filtradas. Não seria mais complicado (menos prático)?
Por favor, me corrija se eu estiver errado.
GOSTEI 0
Afarias
09/09/2003
|É que faço assim: Num form de busca, uso ´Cliente.Locate
|(´CODCLI´,edit1.text,[loPartialKey]);´ para localizar o cliente cfe o
|usuário vai digitando.
Esse tipo de código/interface não condiz com as ´boas práticas´ para aplicações C/S
|Do seu jeito, pelo que entendi, o usuário digita um nome, clica num
|botão ´procurar´ para filtrar o nome num ´select com Like´ e só depois
|escolhe uma das alternativas filtradas.
Correto.
|Não seria mais complicado (menos prático)?
|Por favor, me corrija se eu estiver errado.
Pode ser menos ´prático´, mas garante performance -- é questão de escolha :: o q é mais importante para vc (seu sistema).
T+
|(´CODCLI´,edit1.text,[loPartialKey]);´ para localizar o cliente cfe o
|usuário vai digitando.
Esse tipo de código/interface não condiz com as ´boas práticas´ para aplicações C/S
|Do seu jeito, pelo que entendi, o usuário digita um nome, clica num
|botão ´procurar´ para filtrar o nome num ´select com Like´ e só depois
|escolhe uma das alternativas filtradas.
Correto.
|Não seria mais complicado (menos prático)?
|Por favor, me corrija se eu estiver errado.
Pode ser menos ´prático´, mas garante performance -- é questão de escolha :: o q é mais importante para vc (seu sistema).
T+
GOSTEI 0
Ivonei
09/09/2003
Agradeço a explicação afarias.
Esclareceu-me as dúvidas que tinha a respeito. :D
Abraços
Esclareceu-me as dúvidas que tinha a respeito. :D
Abraços
GOSTEI 0