executing job with non-admin account

hello,
i administer w2k server with sql server and analysis
service installed on it.
some developers use it to tackle their projects.
one of them needs to test job execution and can manage to
create, but is not being able to execute it.
he has registered the server on his desktop enterprise
manager with sql login that is db owner of a given
database.
i wouldn't want to give him sysadmin server role - one
that has more power than he needs.
Would someone knows an alternative way to grant him
rights to run job not being sysadmin?
TIA
Mas"Mas" <anonymous@.discussions.microsoft.com> wrote in message
news:0cbd01c3adf9$b428f1b0$a501280a@.phx.gbl...
> Would someone knows an alternative way to grant him
> rights to run job not being sysadmin?
Oracle? DB2?
One work-around I've found for the permissions problem for the Sqlagent (so
you don't get that infernal database "guest" permissions error) is to set up
the job steps as OS commands that call dtsrun & osql. Just set the user up
as an operator, he'll then be able to run the xp_* sys. procs to run the OS
commands from the job manager, with no SA privileges to worry about. But
talk about convoluted! How 'bout a real job/task security model, eh
Microsoft?
You're not the first to complain about this on this forum, it's frequent
question. MS's security model is - well - unique in the industry in this
regard. The answer in these fora so far has been "It's supposed to work that
way." Maybe one of the MVPs who hang out here might write an FAQ that
explains how "It's supposed to work that way" (along with MS's idea of error
handling and load balanced clusters). Another Yukon feature to wait/pay for?
Tell you what... Max-DB/SAP-DB & PostgreSQL are coming up close behind and
are going to pass MS if MS doesn't watch out.
--j|||Hi, many thanks! I'll try to workout this way.
Mas
>--Original Message--
>"Mas" <anonymous@.discussions.microsoft.com> wrote in
message
>news:0cbd01c3adf9$b428f1b0$a501280a@.phx.gbl...
>> Would someone knows an alternative way to grant him
>> rights to run job not being sysadmin?
>Oracle? DB2?
>One work-around I've found for the permissions problem
for the Sqlagent (so
>you don't get that infernal database "guest" permissions
error) is to set up
>the job steps as OS commands that call dtsrun & osql.
Just set the user up
>as an operator, he'll then be able to run the xp_* sys.
procs to run the OS
>commands from the job manager, with no SA privileges to
worry about. But
>talk about convoluted! How 'bout a real job/task
security model, eh
>Microsoft?
>You're not the first to complain about this on this
forum, it's frequent
>question. MS's security model is - well - unique in the
industry in this
>regard. The answer in these fora so far has been "It's
supposed to work that
>way." Maybe one of the MVPs who hang out here might
write an FAQ that
>explains how "It's supposed to work that way" (along
with MS's idea of error
>handling and load balanced clusters). Another Yukon
feature to wait/pay for?
>Tell you what... Max-DB/SAP-DB & PostgreSQL are coming
up close behind and
>are going to pass MS if MS doesn't watch out.
>--j
>
>.
>