Det är inte ovanligt att man vill ha ett enda skript för att implementera en förändring. Saken är den att ett sådant skript måste köras av en avancerad användare, eftersom det måste ha systembehörighet på ALLA nivåer. Detta innebär vanligtvis ett DBA-konto, helst ett applikationskonto men annars SYSTEM eller SYS.
Så skriptet du vill ha skulle se ut så här:
grant select on user_a.t23 to user_b
/
grant select on user_a.t42 to user_b
/
create view user_b.v_69 as
select t23.col1, t42.col2
from user_a.t42
join user_a.t23
on (t42.id = t23.id)
/
grant select on user_b.v_69 to user_c
/
Ett vanligt scenario är att vi har en svit med individuella skript som har skrivits för att köras av olika användare men som vi nu behöver bunta ihop till en enda distribution. De ursprungliga skripten innehåller inte schemanamnen, och det finns många goda skäl till varför vi inte skulle vilja hårdkoda dem i skripten.
Ett sätt att bygga det huvudskriptet är att använda ändra CURRENT_SCHEMA-syntaxen:
alter session set current_schema=USER_A
/
@run_grants_to_userb.sql
alter session set current_schema=USER_B
/
@create_view69.sql
@run_grants_to_userc.sql
Vi behöver fortfarande en DBA-användare för att köra huvudskriptet. En fördel med att byta det aktuella schemat är att det tillåter oss att distribuera objekt som databaslänkar, som på grund av syntaxen inte kan ha schemanamnet i sin deklaration. En sak är att användaren inte ändras, så ett skript som använder USER pseudo-kolumnen kan ge oönskade resultat.