Erro na SQL das consultas

Bugs
#1

Até a versão 9.9 a SQL a abaixo funcionava normalmente nos formulários GRID/CONSULTA (retornava os campos):
SELECT
IDF_ITEM,
DES_ITEM,
IDF_OPCAO,
QTD_VAGASTOTAL,
QTD_VAGASDEFICIENTE,
TOT_INSCRICAO,
TOT_INSCRICAODEFICIENTE
FROM
CONCURSO_OPCOES_ITENS
where exists (select * from concurso_opcoes
where idf_opcao = concurso_opcoes_itens.idf_opcao
and idf_concurso = 0[vidf_concurso])

order by IDF_OPCAO

Hoje na versão 9.10, ao salvar essa SQL, a aplicação perde todos os campos já configurados.

Para não perder os campos tenho que remover a cláusula WHERE. Esse é um exemplo, outras formas de montagem quando existe o WHERE composto, também apresenta o mesmo erro. Assim fico impedido de dar manutenção nos formulários de consulta existentes.

#2

Use where dinâmico com a macro sc_select_where

#3

Select composto (com mais de uma tabela) fica inviável. E outra coisa, como que um recurso que funcionava na versão anterior, deixa de funcionar na nova versão? Voltamos aos primórdios do SC? Quando a cada versão era uma surpresa diferente…

#4

Eu já mais usaria um select assim independente da versão.

#5

Olá, fiquei curioso agora, como que você faria isso então? Usaria uma view? Porque fugir do select composto no caso dele fica bem difícil…

#6

Caro @amnalon,

Realizamos alguns testes na versão mais recente do Scriptcase (9.10.005(2)), com um SQL semelhante ao que foi informado em termos de estrutura, e os campos chamados nesse mesmo SQL estão sendo trazidos normalmente para a aplicação, tanto em termos de interface como também de aplicação em tempo de execução.

Existe alguma outra particularidade de sua aplicação que você poderia compartilhar conosco para que possamos simular o problema? Caso exista, ficamos no aguardo do vosso feedback para prosseguirmos. Se não for problema também, fique à vontade para enviar sua aplicação através do endereço de email bugs@scriptcase.com.br.

Nossos cumprimentos!

#7

Usar INNER JOIN, modelar adequadamente uma base de dados. (Em resposta a @DevFullTime).

Primeiro, para quem conhece SQL mais a fundo sabe que sub querys são um veneno para performance em consultas SQL. Somente em casos extremos. Segundo, novamente para quem realmente conhece SQL sabe que em sub querys, essas são executadas primeiro, e seu resultado buferizado (memória). Terceiro, SELECT * <–, além de obter todos as colunas da tabela, pode também trazer inúmeros registros (Talvez fosse menos pior um SELECT COUNT(*)).

Mas o problema se resolve com minha sugestão anterior.

Possivelmente o colega mexeu na estrutura do SQL com a consulta pronta e o SC se obriga a recriar todas as colunas, isso é normal desde sempre.

2 Curtidas
#8

Tinha essa SQL funcionando:
SELECT
IDF_ITEM,
DES_ITEM,
IDF_OPCAO,
QTD_VAGASTOTAL,
QTD_VAGASDEFICIENTE,
TOT_INSCRICAO,
TOT_INSCRICAODEFICIENTE
FROM
CONCURSO_OPCOES_ITENS
where exists (select * from concurso_opcoes
where idf_opcao = concurso_opcoes_itens.idf_opcao
and idf_concurso = 0[vidf_concurso])

order by IDF_OPCAO

Mudei para essa: (adicionando 1 campo)
SELECT
IDF_ITEM,
DES_ITEM,
IDF_OPCAO,
QTD_VAGASTOTAL,
QTD_VAGASDEFICIENTE,
TOT_INSCRICAO,
TOT_INSCRICAODEFICIENTE,
TOT_INSCRICAOPPP
FROM
CONCURSO_OPCOES_ITENS
where exists (select * from concurso_opcoes
where idf_opcao = concurso_opcoes_itens.idf_opcao
and idf_concurso = 0[vidf_concurso])

order by IDF_OPCAO

Quando salva a lista de campo some e aparece Bad Get Column Meta ()

E isso acontece em todos os SQL compostos que eu tenho e que funcionavam.

Inner join, left join, qualquer montagem como eu disse acima apresenta o mesmo erro. Eu usei essa SQL, pois é ela que eu preciso ajustar no momento (adicionar 1 campo) e na versão nova não consigo salvar, sem peder a estrutura da consulta que já estava pronta e funcionando. É temerário eu adicionar 1 campo a algo que estava funcionando e simplesmente para de funcionar. Não estou criando uma SQL apenas ajustando. Se é bonita ou feia, se é adequada ou não. Para mim não importa. O fato é que estava funcionando e agora não funciona mais.
Alias a edição da SQL da consulta que não está funcionando.

Detalhe eu utilizo o Firebird 3.0.

#9

Vou repetir, quando se muda a estrutura do SQL é normal sumir os campos.

Tem que adiciona-los novamente. Quanto ao resto, continua cometendo os mesmos erros iniciais.

#10

Vc está equivocado. Nunca sumiu os campos. Aparece os campos novos para ser adicionados a exibição ou utilizado nas quebras ou filtragens.

Seria improdutivo se toda vez que adicionar um campo ao select da consulta, eu ter que refazer toda a consulta.

#11

Pelo seu post inicial, você mesmo fala que a consulta perde todos campos configurados.

Então não sei onde há equívoco.

E é isso mesmo, se mexer na estrutura do SQL tem que adicionar os campos novamente e reconfigura lós.

Doei meu tempo aqui para tentar ajudar orientando sobre sua query e como deve fazer para adicionar where dinâmico.

Boa sorte aí com seu problema.