Ao tentar fazer um select com uma condição, não retorna o resultado:
e meu comando SQL:
SELECT liv_preco FROM livro WHERE liv_preco > 50 AND ass_sigla like'%BAN%';
Meus dados na tabela livro são.
no seu select você pede para retornar o registro em que LIV_PRECO seja maior que 50 E ASS_SIGLA como “BAN”.
Na imagem está claro que o único registro acima de 50 tem ASS_SIGLA diferente de “BAN”.
Se você espera que retornem os três registros (dois com ASS_SIGLA como “BAN” e LIV_PRECO maior que 50, troque o AND por OR
Observando o select e os dados no banco, posso afirmar, com toda a certeza, que o resultado da consulta está correto.
Diferente de outros bancos (como o mysql, por exemplo), o oracle segue uma linha, digamos assim, mais ortodoxa e considera que '%BAN%' não inclui coisas como 'banco de dados para web', mesmo que haja a combinação das letras requeridas.
O que acontece é que, por alguma razão, a cláusula like, no oracle, é case sensitive.
Ou seja, se você alterar tua query para SELECT liv_preco FROM livro WHERE liv_preco > 50 AND UPPER(ass_sigla) like'%BAN%'; muito provavelmente terá mais êxito.
Lembre-se, o teu select deve ser sempre coerente com o que você está buscando.
P.S.: Não lembro se o oracle aceita o ILIKE e nem qual seu comportamento neste caso.
verdade não tinha percebido
quando coloco essa outra condição ele não traz nenhum resultado.
SELECT liv_preco,ass_sigla FROM livro WHERE liv_preco>50 OR upper(ass_sigla) like'P%';sendo que existe um registro que se encaixe nessa condição
Tenta assim:
SELECT liv_preco,ass_sigla FROM livro WHERE liv_preco>50 or upper(ass_sigla) like UPPER('P%');`man ele apresentou o mesmo resultado
Quando coloco essa condição ele não traz nenhum resultado poderia me ajudar.
SELECT liv_preco,ass_sigla FROM livro WHERE liv_preco > 50 or upper(ass_sigla) like'P%';
e tentei dessa forma
SELECT liv_preco,ass_sigla FROM livro WHERE liv_preco > 50 or upper(ass_sigla) like UPPER('P%');
Mas nenhuma deu certo
Teoricamente, o operador or deveria trazer tudo que combine com uma das cláusulas ou com a outra. Se fizer elas separadas?
como assim separadas
Isso
SELECT liv_preco,ass_sigla FROM livro WHERE liv_preco > 50 or upper(ass_sigla) like UPPER('P%');
É o mesmo que isso
SELECT liv_preco,ass_sigla FROM livro WHERE liv_preco > 50
UNION
SELECT liv_preco,ass_sigla FROM livro WHERE upper(ass_sigla) like UPPER('P%');
Como pode ver, são duas queries unidas em uma, pelo operador OR, o que, grosseiramente, indica que você quer qualquer resultado onde o valor de liv_preco seja maior que 50 (apenas os maiores que 50, iguais ou menores não servem) ou onde o valor de ass_sigla seja iniciado em P e tenha qualquer coisa após isso.
Você pode executá-las isoladamente e ver qual delas não está atendendo aos critérios desejados:
SELECT liv_preco,ass_sigla FROM livro WHERE liv_preco > 50
E depois
SELECT liv_preco,ass_sigla FROM livro WHERE upper(ass_sigla) like UPPER('P%');
Assim você consegue ver se ambas trazem resultados ou se alguma delas falha.
É importante ressaltar, também, o seguinte: a query que você criou utiliza-se do operador OR, que é a representação do operador lógico OR, cuja funcionalidade se baseia em sempre procurar uma condição verdadeira numa expressão lógica. A tabela-verdade deste operador é:
Condição 1 Condição 2 Resultado
V V V
V F V
F V V
F F F
Ou seja, a única possibilidade para que nenhum resultado seja obtido na query é que as duas condições sejam falsas, o que significa que nem a primeira condição (liv_preco > 50) e nem a segunda (upper(ass_sigla) like upper(‘P%’)) possuem correspondentes
Use um collatation que seja case insensitive. Usar UPPER deve funcionar em vários casos mas é meio que um chuncho, e se o collatation do campo estiver “errado” pode até ser que acentos não sejam tratados como você esperaria, por exemplo.
@Kronal, neste caso em específico, nenhum dos valores presentes na coluna ass_sigla possui acento, logo, o UPPER deveria funcionar, não?
To vendo pelo menos um acento ali! rs Mas o jeito correto é usar um collation insensitive, não tem porque não fazer isso. OP ainda poderia ter mudado o tipo do collation da própria coluna para nem sequer precisar usar UPPER nem conversão usando COLLATE, caso esse tipo de busca seja comum.
@Kronal, estamos falando de uma pessoa que, pelo que percebo, está começando com banco de dados. Creio que o que ele fez foi criar a tabela e começar a testar o CRUD quando encontrou dificuldades.
Tudo o que está na tabela deve ter pego as configurações padrão. Estas configurações podem mudar de coluna para coluna?
Os valores da coluna ass_sigla não tem acentos. Só os valores da coluna LIV_TITULO que estão acentuados.
Ah sim, desculpa olhei a coluna errada.
Por isso era bom já ser introduzido ao fato de que strings tem ordenação e igualdade que depende do “idioma” que foi definido para eles, em lugar de apresentar uma solução que depois vai trazer problemas.
Sem contar que mandar usar UPPER falha em esclarecer o motivo dele ter falhado, que não é obvio, e o motivo se deve ao fato de que a comparação está sendo feita de forma case-sensitive é devido ao collation da coluna. É simplesmente errado dizer que tudo é case-sensitive como você fez aqui:
Isso além de ser errado, BAN pode ou não fazer match só depende do collation usado, isso não é particular do Oracle, outros SGBDs também tem suporte a collations.
Não estou questionando o uso ou a aplicação de collations.
O que estou dizendo é que, como iniciante, ele pode nem imaginar o que é isso, se usa colher ou garfo para comer, entendeu?
Aliás, a maioria dos desenvolvedores vai precisar apenas dos dados de conexão e do que precisa ser feito. Dificilmente eles vão parar suas atividades para focar em qual collation o banco usa.
Isso, com certeza, é uma das tarefas do DBA. Talvez um desenvolvedor PL/SQL vá se atentar a isso também.
Eu discordo do que disse sobre ele ser iniciante e que ele deveria ser introduzido a isso ou aquilo. O aprendizado é gradual. Neste momento o importante é saber como funciona. Depois devem vir as particularidades.
E por isso explicar errado não adianta, a explicação é: collations. Use uma que seja CI.
É sim, assim como também deveria ser conhecimento de quem escreve SQL.
Enfim você acha que vale a pena simplificar ao ponto de desinformar o cara e deu uma solução que resolve, não tem muito mais que discutir…
Se é resolver por resolver eu também dei a solução e ele pode usar sem entender porque, exceto que não tentei dar uma explicação errada pra ele. Que é acho que é sim um problema.