ya gotta love them new triggers in 8i.
I used a similar scheme to keep duhvelopers
from changing the passwords on common
development accounts, because they would
promptly forget them and call the DBA.
Jared
On Thursday 05 July 2001 09:21, JOE TESTA wrote:
> yeppers, if you want to prevent dd
yeppers, if you want to prevent ddl on tables when you are
required to give out the schema owner password, you put those triggers on all of
the objects. This assumes the user logging does NOT have alter any
trigger. The triggers are owned by a separate userid and look like
this(besides you
So what your DDL triggers are doing. And if they do not allow DDL to work
how you can execute DDL - disabling these triggers?
Alex Hillman
-Original Message-
Sent: Thursday, July 05, 2001 8:00 AM
To: Multiple recipients of list ORACLE-L
i try to play by the same rule as you.
but if i
paquette stephane wrote:
>
> Hi all,
>
> I'm a fan of having the processing done by a user
> different than the owner of the data.
> Am I alone ?
>
> For example, we're on a datawarehouse system where the
> data owner is DWH. The etl tool repository owner is
> TOOL_POWERMART and the reporting t
A couple of other reasons for this approach:
When you create a DAD in Oracle Application Server, you can choose to store
the password in the config file. On version 3.02 it is in unencrypted form
and is optional. On 4.x it's encrypted and mandatory (unless you cheat and
remove the password entr
i try to play by the same rule as you.
but if i can't then i put the "ddl" triggers on the tables owned by the
schema owner, which keeps at least the strucutures from being altered.
joe
paquette stephane wrote:
>
> Hi all,
>
> I'm a fan of having the processing done by a user
> different than
Stephane,
I'm sure they would prefer to operate as the schema owner but to me it's sloppy
practice.
You're right; create the objects as DWH and grant the necessary permissions to
the application users.
That way only the schema owner has 'admin' rights (create, drop, alter etc.).
If they can't