- Este tópico contém 6 respostas, 3 vozes e foi atualizado pela última vez 15 anos, 4 meses atrás por
burga.
-
AutorPosts
-
4 de novembro de 2010 às 10:04 pm #96750
mpvargas
ParticipanteCaros amigos,
Estou com um problema para criar uma VIEW.Quando executo as queries separadamente, elas funcionam.
Quando tento criar a view com o UNION, ele dá problema de permissão.Agradeço desde já pela ajuda de todos.
Segue a VIEW
CREATE VIEW “L_ACADEMICO”.”VIBIBMAT0″
AS
(SELECT TC.COD_PESSOA CODIGO
,TO_NUMBER(TC.COD_FILIAL_PROF) COD_CAMPUS
,2 TIPO_PESSOA
,’0′ COD_CURSO
,TS.SENHA
FROM FIT.TA_CAD_PROFESSOR TC,
FIT.TS_REL_USER_SENHA TS
WHERE TC.DT_SAIDA_DEPTO IS NULL
AND TS.COD_PESSOA = TC.COD_PESSOA)
UNION
(SELECT TC.COD_PESSOA CODIGO
,TO_NUMBER(TC.COD_FIP) COD_CAMPUS
,1 TIPO_PESSOA
,COD_CURSO
,TS.SENHA
FROM FIT.TA_PERF_SIT_ALUNO_COMB TC
,FIT.TA_CAD_COMBINACAO TD
,FIT.TS_REL_USER_SENHA TS
WHERE TC.COD_FIP = TD.COD_FIP
AND TC.COD_COMBINACAO = TD.COD_COMBINACAO
AND TC.COD_PERIODO = ‘2010-2’
AND TC.SIT = ‘M’
AND TS.COD_PESSOA = TC.COD_PESSOA)
;4 de novembro de 2010 às 11:33 pm #96753Ishii
ParticipanteOlá,
Já testou se há grants de select para essas tabelas todas?
[]s Ishii
4 de novembro de 2010 às 11:45 pm #96754mpvargas
ParticipanteFiz um teste e descobri uma coisa…
Mesmo tendo o privilégio de SELECT na tabela, não é permitido acessar pela VIEW… dei o privilégio ALL e a VIEW funcionou…
Qual o privilégio devo dar para o usuário para a VIEW funcionar, sem ter que dar o privilégio ALL?
Obrigado.4 de novembro de 2010 às 11:53 pm #96755mpvargas
ParticipanteFala Ishii, tudo blz
Existem os GRANTS de SELECT para todas as tabelas definidos atraves de uma ROLE.
Estava dando erro, mas qdo eu dei o privilégio separado, digo fora da Role, aí funcionou… Estranho, né? hehehe5 de novembro de 2010 às 2:24 am #96759burga
ParticipanteTambém já tive esse problema…
Isso ocorre porque objetos utilizados em PROCEDURES, FUNCTIONS e VIEWS precisam de priviégios diretos e não através de ROLES, pois sempre que algum código desses é executado, todas as roles são desabilitadas. Isso rodando com “definer’s rights”.
http://download.oracle.com/docs/cd/B19306_01/network.102/b14266/authoriz.htm#i1007304
5 de novembro de 2010 às 5:02 pm #96767mpvargas
ParticipanteValeu amigos, obrigado pela ajuda.
Aproveitando o tópico, gostaria de fazer uma pergunta que parece meio óbvia, mas me deixou na dúvida.
Quando criamos uma view que aponta para várias tabelas de schemas diferentes e damos um grant para um determinado usuário, este usuário deverá ter acesso a TODAS as tabelas existentes na view?
5 de novembro de 2010 às 7:33 pm #96771burga
Participante[quote=”mpvargas”:1ia3elm2]Valeu amigos, obrigado pela ajuda.
Aproveitando o tópico, gostaria de fazer uma pergunta que parece meio óbvia, mas me deixou na dúvida.
Quando criamos uma view que aponta para várias tabelas de schemas diferentes e damos um grant para um determinado usuário, este usuário deverá ter acesso a TODAS as tabelas existentes na view?[/quote]
Depende de qual atribuição (definer’s/invoker’s) a VIEW…
Imagine que a VIEW foi feita com definer’s rights (ou seja, a VIEW será executada com os privilégios de seu owner), então quem deve ter os grants pros objetos acessados pela VIEW é o OWNER da VIEW. Agora, se a VIEW foi feita com invoker’s rights, então quem deve ter privilégios sobre os objetos é o usuário que está acessando a VIEW, pois ela será executada com os privilégios do usuário que a está acessando.
No final, algum usuário terá que ter os grants para acessar os objetos que a VIEW acessa, seja o OWNER da VIEW, seja os usuários com permissão de acesso a ela.
EDIT:
Falei besteira, pra VIEW acho que é só o OWNER dela mesmo que precisa dos grants, o que eu disse é válido pra PROCEDURES e FUNCTIONS (que é o meu caso)… -
AutorPosts
- Você deve fazer login para responder a este tópico.