Het is niet ongebruikelijk om een enkel script te willen hebben om een wijziging door te voeren. Het punt is dat zo'n script moet worden uitgevoerd door een hoofdgebruiker, omdat het systeemrechten op ELK niveau moet hebben. Dit betekent meestal een DBA-account, bij voorkeur een applicatie-account maar anders SYSTEM of SYS.
Het gewenste script ziet er dus als volgt uit:
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
/
Een veelvoorkomend scenario is dat we een reeks afzonderlijke scripts hebben die zijn geschreven om door verschillende gebruikers te worden uitgevoerd, maar die we nu moeten bundelen in een enkele implementatie. De originele scripts bevatten de schemanamen niet, en er zijn veel goede redenen waarom we ze niet hardcoderen in de scripts.
Een manier om dat hoofdscript te bouwen, is door de CURRENT_SCHEMA-syntaxis te wijzigen:
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
We hebben nog steeds een DBA-gebruiker nodig om het hoofdscript uit te voeren. Een voordeel van het omschakelen van het huidige schema is dat het ons in staat stelt objecten zoals databasekoppelingen te implementeren, die door een eigenaardigheid van de syntaxis de schemanaam niet in hun verklaring kunnen hebben. Een probleem is dat de gebruiker niet verandert, dus een script dat de USER-pseudokolom gebruikt, kan ongewenste resultaten opleveren.