FIND com cláusula WHERE

Discussão em 'Progress 4GL' iniciado por alexandre.hubner, Março 2, 2010.

  1. alexandre.hubner

    alexandre.hubner Sem Pontuação

    Bom dia pessoal.

    Gostaria de saber se é do conhecimento de alguém a seguinte situação:

    Preciso realizar um FIND, com 3 cláusulas WHERE, sendo que terei valor DEFINIDO para apenas UMA delas.
    As outras quero procurar "tudo".
    Exemplo:
    Código:
    ------------------------------------------------------------------------------------------------------------------------
    FIND FIRST doc-orig-nfe WHERE doc-orig-nfe.cnpj           = fi-cnpj:SCREEN-VALUE
                                             AND doc-orig-nfe.nro-docto   = "*"    
                                             AND doc-orig-nfe.dt-emissao = "*"   
                 USE-INDEX unico NO-LOCK NO-ERROR.
    ------------------------------------------------------------------------------------------------------------------------
    Só que no exemplo acima, utilizei o "*" para representar o "TUDO". E isto não funciona!

    Sei que pode parecer "viagem" mas fiquei realmente curioso para saber se o progress realiza consultas neste formato.

    Obrigado!
  2. kirchner

    kirchner Membro Participativo Moderador

    Alexandre,

    A cláusula WHERE serve para filtrar os resultados. Se você não quer filtrar por determinada coluna/atributo, não utiliza WHERE para esta. Esta é a melhor forma.

    Se ainda assim você quiser um filtro p/ TUDO, tenta :

    Código:
    AND colunaN MATCHES "*"
    Eu acredito que o Progress não vai otimizar esta situação e vai analisar todos os registros retornados.
  3. alexandre.hubner

    alexandre.hubner Sem Pontuação

    Obrigado Marcos! Resolveu ao meu problema!

    No meu caso será útil pois os valores dos "filtros"/cláusulas, serão PREENCHIDOS (ou não) em uma tela.
    E na minha tela, tenho os campos cfe abaixo:

    Momento 1:
    CPNJ: "987654000123"
    DATA: ""
    DOCT: ""
    ---BOTAO-BUSCAR---

    Momento 2:
    CPNJ: "987654000123"
    DATA: "02/03/2010"
    DOCT: ""
    ---BOTAO-BUSCAR---

    Momento 3:
    CPNJ: ""
    DATA: "02/03/2010"
    DOCT: "01253"
    ---BOTAO-BUSCAR---

    E assin por diante...

    Poderei ou não ter os valores dos campos - eles poderão ser nulos! E quero otimizar meu código!

    Novamente obrigado e um abraço!
  4. kirchner

    kirchner Membro Participativo Moderador

    Alexandre,

    Entendi a situação, mas é importante lembrar que otimizar codificação não é otimizar código.
    Seu código pode estar menor, mais enxuto, etc, mas não necessariamente mais rápido. Se desempenho em tempo de execução não é importante tudo bem. Mas em muitos casos é.

    Vale lembrar que o Progress não realiza otimização em tempo de execução. Todo o plano de acesso aos dados é gerado no momento da compilação. Inclusive a escolha dos índices.
    Isso quer dizer que um índice bom para um conjunto de parâmetros pode ser terrível para outros. E como você vai escolher no momento da compilação, só terá uma opção.
    Se a tabela é grande, isso pode ser um problema.

    Talvez uma opção seria uso de queries dinâmicas (mais trabalhoso).
  5. alexandre.hubner

    alexandre.hubner Sem Pontuação

    Perfeitamente Marcos. Tenho consciência de que isto não significará necessariamente otimização de tempo de execução.
    Sobre as queries dinâmicas, não conheço, mas se você mesmo sugeriu que são mais trabalhosas, deixemos de lado neste momento...
    Apenas mais uma dúvida (se é que você poderá me responder)...
    O comando de comparação MATCHES, só funciona com o tipo CHAR ou LONGCHAR. Não funciona com o tipo DATE.
    E se eu quiser utilizar da mesma lógica, mas para um campo que contenha (ou não) uma data?

    Novamente obrigado!
  6. kirchner

    kirchner Membro Participativo Moderador

    Alexandre,

    Não parei para pensar nisso, mas MATCHES não vai resolver para datas.

    Uma tentativa:
    WHERE campo1 MATCHES "*" AND (campoData = variavelData OR variavelData = ?)

    Esse tipo de expressão resolve o problema, mas novamente, pode gerar uma lentidão significativa.
    Aqui estou assumindo que o tipo é DATE mesmo. DATE não pode ser vazio (''), então usei nulo (?).

Compartilhe esta Página