Menu de navegação

[Douglas Amaral FernandesParticipante]

Estou com uma situação estranha nessa query
OPEN CUR_OUT FOR
SELECT U.COD_IBGE,
WEB.VERSAO,
W.ESTENT,
W.CGCENT,
REGEXP_REPLACE(W.IEENT, ‘[./-]’, ”) IEENT,
WEB.URL,
W.Seq_Cliente,
W.CODCLI,
W.ROWID
FROM DCNFE_CLIENTE_WINTHOR W,
DCHED_UF U,
DCNFE_RELACAO_WEBSERVICES WEB
WHERE W.ESTENT = U.UF
AND WEB.SERVICO = ‘NfeConsultaCadastro’
AND U.COD_IBGE = WEB.COD_IBGE
AND LENGTH(W.CGCENT) > 12
— AND SEQ_CLIENTE in (1064, 1065)
AND UPPER(ESTENT) = ‘BA’
AND IEENT <> ‘ISENTO’;

Quando eu executo na forma que esta ai agora, ela não me retorna as linhas com os seguintes códigos
CODCLI IN (163274, 163288, 164362, 125563, 117101, 164731, 164206)
…

Mais quando eu forço, colocando esse ‘IN’ no where ela me retorna….
oq pode estar errado

E assim me retorna resultado
SELECT U.COD_IBGE,
WEB.VERSAO,
W.ESTENT,
W.CGCENT,
REGEXP_REPLACE(W.IEENT, ‘[./-]’, ”) IEENT,
WEB.URL,
W.Seq_Cliente,
W.CODCLI,
W.ROWID
FROM DCNFE_CLIENTE_WINTHOR W,
DCHED_UF U,
DCNFE_RELACAO_WEBSERVICES WEB
WHERE W.ESTENT = U.UF
AND WEB.SERVICO = ‘NfeConsultaCadastro’
AND U.COD_IBGE = WEB.COD_IBGE
AND LENGTH(W.CGCENT) > 12
— AND SEQ_CLIENTE in (1064, 1065)
AND UPPER(ESTENT) = ‘BA’
AND W.CODCLI IN (163274, 163288, 164362, 125563, 117101, 164731, 164206)
AND IEENT <> ‘ISENTO’;

O erro ñ é na consulta ñ… era no outro sistema que recebe, essas informações

[José Laurindo ChiappaModerador]

Bom, a primeira pergunta é : vc ** executou ** ambas as queries manualmente, por fora da Aplicação (via sql*plus, digamos) e *** TEM TOTAL CERTEZA *** que realmente Não Aparecem linhas/registros com CODCLI 163274, 163288, 164362, 125563, 117101, 164731, 164206 ??? Não é caso de , digamos, o resultset não vir ordenado e esses registros aparecem em posições diferentes, vc OLHOU DIREITINHO e realmente os registros não aparecem, mesmo ???
Se SIM, como eu vejo que o resto do SQL está ** totalmente Idêntico ** nas duas execuções (a linha do CODCLI IN …. sendo a única diferença) eu acho q tá comprovado que vc tem algo/alguma coisa no database ALTERANDO a query, tem alguma Cláusula a mais sendo adicionada : pois se não fosse assim, quando vc Remove o CODCLI na WHERE deveriam retornar registros de QUALQUER CODCLI – é por definição, o normal é que quando vc não filtra uma coluna ela se torna Irrelevante e portanto devem retornar linhas/registros para SEJA QUAL FOR o conteúdo da coluna….

Vc ** vai ter ** que acionar seu DBA pra te dar Suporte nisso, mas entre outras opções esse “alguma coisa” poderia ser OU view (simples OU MATERIALIZED VIEW) que tem condições/parâmetros, OU uma Policy de segurança que adiciona filtros automaticamente nessa coluna CODCLI (veja DBMS_FGAC e correlatos no manual Oracle para mais refs), OU algum SQL PROFILE que esteja alterando teu SQL, OU algum índice que não traga todos os CODCLI (veja nos manuais sobre Function Based Index para mais refs, e http://use-the-index-luke.com/sql/where-clause/partial-and-filtered-indexes dá um exemplinho), é algo por aí, imagino…

Com a ajuda do seu DBA, faça um trace de uma sessão sql*plus rodando a query sem o CODCLI IN …. , outro trace de outra sessão rodando a mesma query acrescida do CODCLI IN …. , e depois faça um tkprof dos dois trace files com a opção SYS=YES, veja lá o que vc encontra de diff entre as duas, especialmente planos de execução… Adicionalmente, seu DBA deveria também CONFIRMAR o que são esses objetos que vc usa no FROM (ie, se são views, tabelas próprias, sinônimos apontando pra outro objeto, etc) E consultar o dicionário procurando por FGAC Policies/Row-Level Security, SQL Profiles, etc…

[]s

Chiappa

OBS : há uma pequena chance de BUG, em especial se vc estiver usando banco 10g ou 11g sem patchset nenhum (especialmente no Release 2, tanto 10g quanto 11g tiveram alguns bugs de dados não retornados em JOINs com condições específicas – normalmente com SUB-QUERY, o que não é seu caso, mas vale a pena checar no Suporte Oracle a possibilidade…

[Autor]

Posts