erro em upper

[cjp]

Pessoal, alguém saberia me dizer a causa deste erro: Error BASE/1102 Erro nos parâmetros: UPPER

O trecho do programa está assim:

Código: Selecionar todos

        prod=space(30)
                 @ maxrow()-1,0 say "Procurar:"get prod pict "@!"
                 read
                 prod=alltrim(prod)
                 @ maxrow()-1,0 clear to maxrow()-1,maxcol()
cls
?alias()
?produto
?upper(produto)
wait ""     
                 set filter to prod$upper(produto)
                 go bottom
                 go top
     keyb "y"
     inkey(0)
                 return(2)

No teste acima (com ?), está funcionando. O erro está dando na linha:set filter to prod$upper(produto)

O estranho é que esta linha sempre esteve assim, só agora está dando esse erro.

Estou usando Harbour, acessando a tabela no banco de dados MySQL com RDDINFO.

Alguém me ajuda?

[JoséQuintas]

Tá explicado.
O comando esteve sempre assim, mas não o banco de dados.

Está usando uma biblioteca que deixa o uso "parecido" com DBF, tão parecido que faz esquecer do básico.

Não existe a função Upper() no MySQL, por isso está acusando erro.

Dependendo da configuração no MySQL, não há diferenciação entre maiúscula e minúscula.
Mas se precisar, terá que pesquisar o comando equivalente no MySQL.

[cjp]

De fato, Quintas, vc tem razão.

Eu estou usando um dbedit(), com função de usuário. Ao teclar P no dbedit, abre a pesquisa por parte do campo. Mas, como na tabela, pode estar com maiúscula ou minúscula, eu preciso do Upper para pesquisar.

Se eu não puder usar o Upper, eu acho que vou ter que mudar totalmente o programa, pois ele terá que pesquisar novamente na tabela, salvo engano.

O que eu acho estranho é que eu já fazia assim antes, mesmo já usando a tabela do banco MySQL. E até faço isso em outros pontos do meu programa.

Tem um trecho assim em outro ponto do meu programa, que funciona:

Código: Selecionar todos

				         @ maxrow()-8,0 say "Procurar por:"get exp pict "@!"
				         read
						 cFiltro:= "'"+alltrim(exp)+"'$upper("+cp+")"
				 if lastkey()#27
                            INDEX ON recno() TAG TEMPB TO TEMPBOL FOR &cFiltro.

Faz diferença? Por que deste jeito funciona com o upper e do jeito anterior não?

[JoséQuintas]

Depende do que foi feito na biblioteca.
Lembre-se que é impossível a biblioteca traduzir tudo, já que poderia ser SET FILTER TO MinhaFuncao() e a função inteira teria que ser convertida pra MySQL... teria que ter embutido um compilador Harbour.

Pode ser que o SET FILTER seja tratado diferente do "FOR".

Esquisito que a mensagem não parece com as mensagens normais do MySQL.

Não custa tentar, filtro em formato xbase:

Código: Selecionar todos

cFiltro := ["]  + prod + [" $ Upper( FIELD->Produto )]
SET FILTER TO &cFIltro

filtro em formato MySQL:

Código: Selecionar todos

cFiltro := [UCASE( PRODUTO ) LIKE '%] + prod + [%']
SET FILTER TO ( cFiltro )

Também precisa confirmar área em uso, e nome do campo, já que pelo jeito se trata de campo diferente.

[alxsts]

Olá!

Este erro ocorre quando o valor passado como parâmetro de entrada para a função Upper() é de tipo diferente de carácter.

[cjp]

Quintas, no primeiro caso (em xbase), deu o mesmo erro. No segundo (em MySQL), tá dando o seguinte erro: Erro nos parâmetros: condicional.

Alexandre, eu acho que vc tem razão, mas como? Como não seria caractere? Certeza que o campo da base é caractere, e a variável também.

[cjp]

Pessoal, descobri o problema: tinha um registro na tabela que estava com o campo produto como NULL. Colocando-o com um espaço em branco, não deu mais erro.

Ainda preciso me adaptar a essas particularidades das bases MySQL.

Alexandre, vc tinha razão. Mas bem que o Harbour poderia evitar esse erro, né?

Obrigado a todos que cooperaram.

[Itamar M. Lins Jr.]

Mas bem que o Harbour poderia evitar esse erro, né?

O harbour já reconhece compo NULL e NIL
Tem como evitar isso, eu uso assim:

Código: Selecionar todos

NovoCampo := iif(campox==Nil,"",campox)
NovoCampo := iif(campox==Nil,0,campox)

Saudações,
Itamar M. Lins Jr.

[cjp]

Entendi, Itamar. Só acho que a função upper poderia reconhecer automaticamente quando o campo fosse NULL.

[Eolo]

descobri o problema: tinha um registro na tabela que estava com o campo produto como NULL

Cjp, uma “curiosidade”: se esse campo PRODUTO é “chave” (entre aspas), tanto que vc faz um filtro nele, como pode aparecer um registro com ele vazio (seja null ou branco)? Será que não falta cercar, na gravação do registro, que esse campo não pode ser vazio? Ou ele pode mesmo ser vazio?

[cjp]

Na verdade esse campo não é chave, meu caro. Só neste trecho do programa eu faço uma pesquisa por ele. Mas tem um outro campo chave nessa tabela, o campo CODPROD. De qualquer forma, esses registros não precisariam estar como NULL.

[Eolo]

Na verdade esse campo não é chave, meu caro

Eu não disse que era um campo chave, no sentido restrito de ter algum índice baseado nele.

Note que escrevi “chave“, entre aspas, e ainda ressaltei o uso das aspas, indicando um outro sentido, qual seja: se vc usa o conteúdo desse campo pra fazer alguma pesquisa, então esse campo é “chave” para vc chegar a um resultado desejado, ou seja, sem o campo vc não chegaria ao resultado. Entendeu? A chave da minha questão foi outra.

[cjp]

Te entendi, meu caro. Realmente este campo não deveria estar como Null. Mas já fiz a correção. Obrigado.

[Itamar M. Lins Jr.]

Resposta do Viktor sobre esta questão:

There are a few potential solutions, but I'm sure it is the best to hide NULLs with empty values by default. Probably the easiest now is to use expression Upper( hb_defaultValue( PRODUTO, "" ) ) and similar, on columns that are nullable.

Saudações,
Itamar M. Lins Jr.

[alxsts]

Olá!

Creio que o mais indicado seja a aplicação receber, do banco, os dados já "limpos". Todos os SGBD tem funções para este tipo de tratamento. No caso do MySQL, é a função IFNULL(). Exemplo:

Código: Selecionar todos

SELECT IFNULL(produto,''), 
       IFNULL(colunaNumerica,0), 
       IFNULL(colunaDate,'1900-01-01'), 
       IFNULL(colunaDateTime,'1900-01-01 00:00:00.000')
  FROM tabela
WHERE condicao
ORDER BY 1

Vale lembrar que no processo inverso (gravação de dados), a aplicação tem que adequar seus dados ao padrão do banco. Especial atenção precisa ser dada a campos alfanuméricos. que podem conter o carácter apóstrofe. (Exemplo: "Caixa d'água"). Isto causa erro no SQL, devendo o apóstrofe ser trocado por dois apóstrofes, como em "Caixa d''água".

Edit: as funções equivalentes em outros SGBDs importantes são NVL() no Oracle, IsNull() no SQL Server.