Grant Control Causes SQL Server Agent job to fail?

I have a SQL Agent job that applies permissions to a SQL Server 2005
database after it has been restored, it executes in management studio,
it even parses when you click parse with the job step. Yet it fails
every time unless I remove this:
GRANT CONTROL ON OBJECT::dbo.usp_AStoredProc
TO "aDomain\aUser"
Errr... Bug?dba
It has been restored from SQL Server 2000? If it has , check out compatibily
level of the database (should be 90)
"dba" <bryanmurtha@.gmail.com> wrote in message
news:1178669352.091335.225000@.n59g2000hsh.googlegroups.com...
>I have a SQL Agent job that applies permissions to a SQL Server 2005
> database after it has been restored, it executes in management studio,
> it even parses when you click parse with the job step. Yet it fails
> every time unless I remove this:
> GRANT CONTROL ON OBJECT::dbo.usp_AStoredProc
> TO "aDomain\aUser"
> Errr... Bug?
>|||"Fails" doesn't give us much to go on. Specify an output file for that job step and post the error
messages here.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"dba" <bryanmurtha@.gmail.com> wrote in message
news:1178669352.091335.225000@.n59g2000hsh.googlegroups.com...
>I have a SQL Agent job that applies permissions to a SQL Server 2005
> database after it has been restored, it executes in management studio,
> it even parses when you click parse with the job step. Yet it fails
> every time unless I remove this:
> GRANT CONTROL ON OBJECT::dbo.usp_AStoredProc
> TO "aDomain\aUser"
> Errr... Bug?
>

Grant Control Causes SQL Server Agent job to fail?

I have a SQL Agent job that applies permissions to a SQL Server 2005
database after it has been restored, it executes in management studio,
it even parses when you click parse with the job step. Yet it fails
every time unless I remove this:
GRANT CONTROL ON OBJECT::dbo.usp_AStoredProc
TO "aDomain\aUser"
Errr... Bug?
dba
It has been restored from SQL Server 2000? If it has , check out compatibily
level of the database (should be 90)
"dba" <bryanmurtha@.gmail.com> wrote in message
news:1178669352.091335.225000@.n59g2000hsh.googlegr oups.com...
>I have a SQL Agent job that applies permissions to a SQL Server 2005
> database after it has been restored, it executes in management studio,
> it even parses when you click parse with the job step. Yet it fails
> every time unless I remove this:
> GRANT CONTROL ON OBJECT::dbo.usp_AStoredProc
> TO "aDomain\aUser"
> Errr... Bug?
>
|||"Fails" doesn't give us much to go on. Specify an output file for that job step and post the error
messages here.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"dba" <bryanmurtha@.gmail.com> wrote in message
news:1178669352.091335.225000@.n59g2000hsh.googlegr oups.com...
>I have a SQL Agent job that applies permissions to a SQL Server 2005
> database after it has been restored, it executes in management studio,
> it even parses when you click parse with the job step. Yet it fails
> every time unless I remove this:
> GRANT CONTROL ON OBJECT::dbo.usp_AStoredProc
> TO "aDomain\aUser"
> Errr... Bug?
>

Grant Control Causes SQL Server Agent job to fail?

I have a SQL Agent job that applies permissions to a SQL Server 2005
database after it has been restored, it executes in management studio,
it even parses when you click parse with the job step. Yet it fails
every time unless I remove this:
GRANT CONTROL ON OBJECT::dbo.usp_AStoredProc
TO "aDomain\aUser"
Errr... Bug?dba
It has been restored from SQL Server 2000? If it has , check out compatibily
level of the database (should be 90)
"dba" <bryanmurtha@.gmail.com> wrote in message
news:1178669352.091335.225000@.n59g2000hsh.googlegroups.com...
>I have a SQL Agent job that applies permissions to a SQL Server 2005
> database after it has been restored, it executes in management studio,
> it even parses when you click parse with the job step. Yet it fails
> every time unless I remove this:
> GRANT CONTROL ON OBJECT::dbo.usp_AStoredProc
> TO "aDomain\aUser"
> Errr... Bug?
>|||"Fails" doesn't give us much to go on. Specify an output file for that job s
tep and post the error
messages here.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"dba" <bryanmurtha@.gmail.com> wrote in message
news:1178669352.091335.225000@.n59g2000hsh.googlegroups.com...
>I have a SQL Agent job that applies permissions to a SQL Server 2005
> database after it has been restored, it executes in management studio,
> it even parses when you click parse with the job step. Yet it fails
> every time unless I remove this:
> GRANT CONTROL ON OBJECT::dbo.usp_AStoredProc
> TO "aDomain\aUser"
> Errr... Bug?
>sql

Good reasons for 'sa' and service accounts passwords to be control

By other than the DBA. We have a security group with our org that wants to
control sa and system accounts for SQL Servers. We're desparately trying to
hold on to our control of these, but need to justify with the business unit.
Anyone got a really great reason not to let a non-DBA control these?
"David T." <DavidT@.discussions.microsoft.com> wrote in message
news:2A6FC7A8-EE65-4DBA-86A2-78C1DD836333@.microsoft.com...
> By other than the DBA. We have a security group with our org that wants
> to
> control sa and system accounts for SQL Servers. We're desparately trying
> to
> hold on to our control of these, but need to justify with the business
> unit.
> Anyone got a really great reason not to let a non-DBA control these?
No, I mostly agree. Accounts and passwords which are shared among groups of
people are inherently insecure. SA should be disabled, and the passwords
for fixed service accounts should be centrally and closely controlled. In
the normal course of things, people should connect with windows integrated
authentication and service accounts should be managed centrally.
But, and this is a _big_ but, a DBA should be a local administrator of any
database server and have sysadmin fixed server role. This will give a DBA
the ability, in a pinch, to reset passwords change service accounts and do
whatever is necessary to react in a "data emergency".
David

Good reasons for 'sa' and service accounts passwords to be control

By other than the DBA. We have a security group with our org that wants to
control sa and system accounts for SQL Servers. We're desparately trying to
hold on to our control of these, but need to justify with the business unit.
Anyone got a really great reason not to let a non-DBA control these?"David T." <DavidT@.discussions.microsoft.com> wrote in message
news:2A6FC7A8-EE65-4DBA-86A2-78C1DD836333@.microsoft.com...
> By other than the DBA. We have a security group with our org that wants
> to
> control sa and system accounts for SQL Servers. We're desparately trying
> to
> hold on to our control of these, but need to justify with the business
> unit.
> Anyone got a really great reason not to let a non-DBA control these?
No, I mostly agree. Accounts and passwords which are shared among groups of
people are inherently insecure. SA should be disabled, and the passwords
for fixed service accounts should be centrally and closely controlled. In
the normal course of things, people should connect with windows integrated
authentication and service accounts should be managed centrally.
But, and this is a _big_ but, a DBA should be a local administrator of any
database server and have sysadmin fixed server role. This will give a DBA
the ability, in a pinch, to reset passwords change service accounts and do
whatever is necessary to react in a "data emergency".
David

Good reasons for 'sa' and service accounts passwords to be control

By other than the DBA. We have a security group with our org that wants to
control sa and system accounts for SQL Servers. We're desparately trying to
hold on to our control of these, but need to justify with the business unit.
Anyone got a really great reason not to let a non-DBA control these?"David T." <DavidT@.discussions.microsoft.com> wrote in message
news:2A6FC7A8-EE65-4DBA-86A2-78C1DD836333@.microsoft.com...
> By other than the DBA. We have a security group with our org that wants
> to
> control sa and system accounts for SQL Servers. We're desparately trying
> to
> hold on to our control of these, but need to justify with the business
> unit.
> Anyone got a really great reason not to let a non-DBA control these?
No, I mostly agree. Accounts and passwords which are shared among groups of
people are inherently insecure. SA should be disabled, and the passwords
for fixed service accounts should be centrally and closely controlled. In
the normal course of things, people should connect with windows integrated
authentication and service accounts should be managed centrally.
But, and this is a _big_ but, a DBA should be a local administrator of any
database server and have sysadmin fixed server role. This will give a DBA
the ability, in a pinch, to reset passwords change service accounts and do
whatever is necessary to react in a "data emergency".
David