Select Banco Oracle não produz resultado?

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.