Re: Misleading "view" ALL_JOBS - really a synonym to USER_JOBS

"Joe Belka" <joe.belka_at_nospam.ntlworld.com> wrote in message news:km6S6.14649$%_1.2555137_at_news2-win.server.ntlworld.com...

> AFAIK, only the user who submitted the job can perform operations on it.
> Even a user with the DBA privilege cannot remove another users job. So

yes, only the user that creates the job can perform operations (with the DBMS_JOB package) on the job.

> ALL_JOBS seems redundant to me.

yes, i suppose you could classify the ALL_JOBS synonym as redundant. in a lot of cases (including this case) redundant is a good thing.

what would happen if ALL_JOBS were not there ? some user would be asking "where is ALL_JOBS ?" there are usually three corresponding names, two of which normal users can query: USER_x and ALL_x.

the ALL_JOBS synonynm is there for good reason, consistency.

>
> Joe Belka.
>
> "Vsevolod Afanassiev" <vafanassiev_at_aapt.com.au> wrote in message
> news:4f7d504c.0106020234.1e968812_at_posting.google.com...
> > Normally, ALL_something, DBA_something, and USER_something are 3
> > different views, but not for jobs (DBMS_JOBS).
> > Look in $ORACLE_HOME/rdbms/admin/catjobq.sql:
> > create public synonym ALL_JOBS for USER_JOBS
> > Isn't it a bit misleading? In one of our applications

having ALL_JOBS as a synonym for USER_JOBS is not at all misleading. ALL_JOBS is a convenience.

and you don't have to refer to the catalog creation scripts to figure this out. there are dictionary views that can tell you the same thing.

> > user A submits a job and user B removes it by selecting from
> > ALL_JOBS - naturally it does not work.

of course it doesn't work. if user A submits the job, then user A is the owner of the job, and user A is the one that should remove the job. i have no problems with that here. just be careful which usernames you grant execute on DBMS_JOB to ... Received on Sat Jun 02 2001 - 20:43:59 CDT