Det er ikke usædvanligt at ville have et enkelt script til at implementere en ændring. Sagen er, at sådan et script skal køres af en superbruger, fordi det skal have systemprivilegier på ALT niveau. Dette betyder normalt en DBA-konto, helst en applikationskonto, men ellers SYSTEM eller SYS.
Så det ønskede script ville se sådan ud:
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
/
Et almindeligt scenarie er, at vi har en suite af individuelle scripts, som er skrevet til at blive kørt af forskellige brugere, men som vi nu skal samle i en enkelt implementering. De originale scripts indeholder ikke skemanavnene, og der er mange gode grunde til, at vi ikke ønsker at hardkode dem i scripts.
En måde at bygge det masterscript på er at bruge ændring af CURRENT_SCHEMA-syntaksen:
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 mangler stadig en DBA-bruger til at køre masterscriptet. En fordel ved at skifte det aktuelle skema er, at det giver os mulighed for at implementere objekter som databaselinks, som på grund af syntaks ikke kan have skemanavnet i deres erklæring. Én ting er, at brugeren ikke ændrer sig, så et script, der anvender USER pseudo-kolonnen, kan give uønskede resultater.