I have this procdure to grant select permission to a developers group on an
SQL Databse. The query executes but never returnes and the permissions are
set. Can anyone tell me why the little world keeps spinning and never
returns. thanks
DECLARE @.cmd as varchar(255)
DECLARE table_names CURSOR FOR
SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
DECLARE @.name as varchar(255)
OPEN table_names
FETCH NEXT FROM table_names INTO @.name
WHILE (@.@.FETCH_STATUS <> 1)
SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
--PRINT @.cmd
EXEC @.cmd
FETCH NEXT FROM table_names INTO @.name
DEALLOCATE table_names
CLOSE table_names
"brymer28303" <brymer28303@.discussions.microsoft.com> wrote in message
news:D3BA7C42-13A0-49EF-A476-3A32121E2D41@.microsoft.com...
>I have this procdure to grant select permission to a developers group on an
> SQL Databse. The query executes but never returnes and the permissions
> are
> set. Can anyone tell me why the little world keeps spinning and never
> returns. thanks
> DECLARE @.cmd as varchar(255)
> DECLARE table_names CURSOR FOR
> SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
> DECLARE @.name as varchar(255)
> OPEN table_names
> FETCH NEXT FROM table_names INTO @.name
> WHILE (@.@.FETCH_STATUS <> 1)
> SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
> --PRINT @.cmd
> EXEC @.cmd
> FETCH NEXT FROM table_names INTO @.name
> DEALLOCATE table_names
> CLOSE table_names
Infinite loop. Your loop doesn't include the FETCH NEXT. Also you should
test for @.@.FETCH_STATUS = 0, since values other that 1 are possible.
Should beL
DECLARE @.cmd as varchar(255)
DECLARE table_names CURSOR FOR
SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
DECLARE @.name as varchar(255)
OPEN table_names
FETCH NEXT FROM table_names INTO @.name
WHILE @.@.FETCH_STATUS = 0
BEGIN
SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
--PRINT @.cmd
EXEC @.cmd
FETCH NEXT FROM table_names INTO @.name
END
CLOSE table_names
DEALLOCATE table_names
David
|||Thanks David
"David Browne" wrote:
>
> "brymer28303" <brymer28303@.discussions.microsoft.com> wrote in message
> news:D3BA7C42-13A0-49EF-A476-3A32121E2D41@.microsoft.com...
> Infinite loop. Your loop doesn't include the FETCH NEXT. Also you should
> test for @.@.FETCH_STATUS = 0, since values other that 1 are possible.
> Should beL
> DECLARE @.cmd as varchar(255)
> DECLARE table_names CURSOR FOR
> SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
> DECLARE @.name as varchar(255)
> OPEN table_names
> FETCH NEXT FROM table_names INTO @.name
> WHILE @.@.FETCH_STATUS = 0
> BEGIN
> SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
> --PRINT @.cmd
> EXEC @.cmd
> FETCH NEXT FROM table_names INTO @.name
> END
> CLOSE table_names
> DEALLOCATE table_names
>
> David
>
Showing posts with label executes. Show all posts
Showing posts with label executes. Show all posts
Thursday, March 29, 2012
Granting Select to an NT Login Group
I have this procdure to grant select permission to a developers group on an
SQL Databse. The query executes but never returnes and the permissions are
set. Can anyone tell me why the little world keeps spinning and never
returns. thanks
DECLARE @.cmd as varchar(255)
DECLARE table_names CURSOR FOR
SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
DECLARE @.name as varchar(255)
OPEN table_names
FETCH NEXT FROM table_names INTO @.name
WHILE (@.@.FETCH_STATUS <> 1)
SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
--PRINT @.cmd
EXEC @.cmd
FETCH NEXT FROM table_names INTO @.name
DEALLOCATE table_names
CLOSE table_names"brymer28303" <brymer28303@.discussions.microsoft.com> wrote in message
news:D3BA7C42-13A0-49EF-A476-3A32121E2D41@.microsoft.com...
>I have this procdure to grant select permission to a developers group on an
> SQL Databse. The query executes but never returnes and the permissions
> are
> set. Can anyone tell me why the little world keeps spinning and never
> returns. thanks
> DECLARE @.cmd as varchar(255)
> DECLARE table_names CURSOR FOR
> SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
> DECLARE @.name as varchar(255)
> OPEN table_names
> FETCH NEXT FROM table_names INTO @.name
> WHILE (@.@.FETCH_STATUS <> 1)
> SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
> --PRINT @.cmd
> EXEC @.cmd
> FETCH NEXT FROM table_names INTO @.name
> DEALLOCATE table_names
> CLOSE table_names
Infinite loop. Your loop doesn't include the FETCH NEXT. Also you should
test for @.@.FETCH_STATUS = 0, since values other that 1 are possible.
Should beL
DECLARE @.cmd as varchar(255)
DECLARE table_names CURSOR FOR
SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
DECLARE @.name as varchar(255)
OPEN table_names
FETCH NEXT FROM table_names INTO @.name
WHILE @.@.FETCH_STATUS = 0
BEGIN
SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
--PRINT @.cmd
EXEC @.cmd
FETCH NEXT FROM table_names INTO @.name
END
CLOSE table_names
DEALLOCATE table_names
David|||Thanks David
"David Browne" wrote:
>
> "brymer28303" <brymer28303@.discussions.microsoft.com> wrote in message
> news:D3BA7C42-13A0-49EF-A476-3A32121E2D41@.microsoft.com...
> Infinite loop. Your loop doesn't include the FETCH NEXT. Also you should
> test for @.@.FETCH_STATUS = 0, since values other that 1 are possible.
> Should beL
> DECLARE @.cmd as varchar(255)
> DECLARE table_names CURSOR FOR
> SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
> DECLARE @.name as varchar(255)
> OPEN table_names
> FETCH NEXT FROM table_names INTO @.name
> WHILE @.@.FETCH_STATUS = 0
> BEGIN
> SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
> --PRINT @.cmd
> EXEC @.cmd
> FETCH NEXT FROM table_names INTO @.name
> END
> CLOSE table_names
> DEALLOCATE table_names
>
> David
>
SQL Databse. The query executes but never returnes and the permissions are
set. Can anyone tell me why the little world keeps spinning and never
returns. thanks
DECLARE @.cmd as varchar(255)
DECLARE table_names CURSOR FOR
SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
DECLARE @.name as varchar(255)
OPEN table_names
FETCH NEXT FROM table_names INTO @.name
WHILE (@.@.FETCH_STATUS <> 1)
SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
--PRINT @.cmd
EXEC @.cmd
FETCH NEXT FROM table_names INTO @.name
DEALLOCATE table_names
CLOSE table_names"brymer28303" <brymer28303@.discussions.microsoft.com> wrote in message
news:D3BA7C42-13A0-49EF-A476-3A32121E2D41@.microsoft.com...
>I have this procdure to grant select permission to a developers group on an
> SQL Databse. The query executes but never returnes and the permissions
> are
> set. Can anyone tell me why the little world keeps spinning and never
> returns. thanks
> DECLARE @.cmd as varchar(255)
> DECLARE table_names CURSOR FOR
> SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
> DECLARE @.name as varchar(255)
> OPEN table_names
> FETCH NEXT FROM table_names INTO @.name
> WHILE (@.@.FETCH_STATUS <> 1)
> SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
> --PRINT @.cmd
> EXEC @.cmd
> FETCH NEXT FROM table_names INTO @.name
> DEALLOCATE table_names
> CLOSE table_names
Infinite loop. Your loop doesn't include the FETCH NEXT. Also you should
test for @.@.FETCH_STATUS = 0, since values other that 1 are possible.
Should beL
DECLARE @.cmd as varchar(255)
DECLARE table_names CURSOR FOR
SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
DECLARE @.name as varchar(255)
OPEN table_names
FETCH NEXT FROM table_names INTO @.name
WHILE @.@.FETCH_STATUS = 0
BEGIN
SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
--PRINT @.cmd
EXEC @.cmd
FETCH NEXT FROM table_names INTO @.name
END
CLOSE table_names
DEALLOCATE table_names
David|||Thanks David
"David Browne" wrote:
>
> "brymer28303" <brymer28303@.discussions.microsoft.com> wrote in message
> news:D3BA7C42-13A0-49EF-A476-3A32121E2D41@.microsoft.com...
> Infinite loop. Your loop doesn't include the FETCH NEXT. Also you should
> test for @.@.FETCH_STATUS = 0, since values other that 1 are possible.
> Should beL
> DECLARE @.cmd as varchar(255)
> DECLARE table_names CURSOR FOR
> SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
> DECLARE @.name as varchar(255)
> OPEN table_names
> FETCH NEXT FROM table_names INTO @.name
> WHILE @.@.FETCH_STATUS = 0
> BEGIN
> SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
> --PRINT @.cmd
> EXEC @.cmd
> FETCH NEXT FROM table_names INTO @.name
> END
> CLOSE table_names
> DEALLOCATE table_names
>
> David
>
Granting Select to an NT Login Group
I have this procdure to grant select permission to a developers group on an
SQL Databse. The query executes but never returnes and the permissions are
set. Can anyone tell me why the little world keeps spinning and never
returns. thanks
DECLARE @.cmd as varchar(255)
DECLARE table_names CURSOR FOR
SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
DECLARE @.name as varchar(255)
OPEN table_names
FETCH NEXT FROM table_names INTO @.name
WHILE (@.@.FETCH_STATUS <> 1)
SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
--PRINT @.cmd
EXEC @.cmd
FETCH NEXT FROM table_names INTO @.name
DEALLOCATE table_names
CLOSE table_names"brymer28303" <brymer28303@.discussions.microsoft.com> wrote in message
news:D3BA7C42-13A0-49EF-A476-3A32121E2D41@.microsoft.com...
>I have this procdure to grant select permission to a developers group on an
> SQL Databse. The query executes but never returnes and the permissions
> are
> set. Can anyone tell me why the little world keeps spinning and never
> returns. thanks
> DECLARE @.cmd as varchar(255)
> DECLARE table_names CURSOR FOR
> SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
> DECLARE @.name as varchar(255)
> OPEN table_names
> FETCH NEXT FROM table_names INTO @.name
> WHILE (@.@.FETCH_STATUS <> 1)
> SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
> --PRINT @.cmd
> EXEC @.cmd
> FETCH NEXT FROM table_names INTO @.name
> DEALLOCATE table_names
> CLOSE table_names
Infinite loop. Your loop doesn't include the FETCH NEXT. Also you should
test for @.@.FETCH_STATUS = 0, since values other that 1 are possible.
Should beL
DECLARE @.cmd as varchar(255)
DECLARE table_names CURSOR FOR
SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
DECLARE @.name as varchar(255)
OPEN table_names
FETCH NEXT FROM table_names INTO @.name
WHILE @.@.FETCH_STATUS = 0
BEGIN
SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
--PRINT @.cmd
EXEC @.cmd
FETCH NEXT FROM table_names INTO @.name
END
CLOSE table_names
DEALLOCATE table_names
David|||Thanks David
"David Browne" wrote:
>
> "brymer28303" <brymer28303@.discussions.microsoft.com> wrote in message
> news:D3BA7C42-13A0-49EF-A476-3A32121E2D41@.microsoft.com...
> >I have this procdure to grant select permission to a developers group on an
> > SQL Databse. The query executes but never returnes and the permissions
> > are
> > set. Can anyone tell me why the little world keeps spinning and never
> > returns. thanks
> >
> > DECLARE @.cmd as varchar(255)
> >
> > DECLARE table_names CURSOR FOR
> > SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
> > DECLARE @.name as varchar(255)
> >
> > OPEN table_names
> > FETCH NEXT FROM table_names INTO @.name
> > WHILE (@.@.FETCH_STATUS <> 1)
> > SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
> > --PRINT @.cmd
> > EXEC @.cmd
> > FETCH NEXT FROM table_names INTO @.name
> > DEALLOCATE table_names
> > CLOSE table_names
> Infinite loop. Your loop doesn't include the FETCH NEXT. Also you should
> test for @.@.FETCH_STATUS = 0, since values other that 1 are possible.
> Should beL
> DECLARE @.cmd as varchar(255)
> DECLARE table_names CURSOR FOR
> SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
> DECLARE @.name as varchar(255)
> OPEN table_names
> FETCH NEXT FROM table_names INTO @.name
> WHILE @.@.FETCH_STATUS = 0
> BEGIN
> SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
> --PRINT @.cmd
> EXEC @.cmd
> FETCH NEXT FROM table_names INTO @.name
> END
> CLOSE table_names
> DEALLOCATE table_names
>
> David
>sql
SQL Databse. The query executes but never returnes and the permissions are
set. Can anyone tell me why the little world keeps spinning and never
returns. thanks
DECLARE @.cmd as varchar(255)
DECLARE table_names CURSOR FOR
SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
DECLARE @.name as varchar(255)
OPEN table_names
FETCH NEXT FROM table_names INTO @.name
WHILE (@.@.FETCH_STATUS <> 1)
SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
--PRINT @.cmd
EXEC @.cmd
FETCH NEXT FROM table_names INTO @.name
DEALLOCATE table_names
CLOSE table_names"brymer28303" <brymer28303@.discussions.microsoft.com> wrote in message
news:D3BA7C42-13A0-49EF-A476-3A32121E2D41@.microsoft.com...
>I have this procdure to grant select permission to a developers group on an
> SQL Databse. The query executes but never returnes and the permissions
> are
> set. Can anyone tell me why the little world keeps spinning and never
> returns. thanks
> DECLARE @.cmd as varchar(255)
> DECLARE table_names CURSOR FOR
> SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
> DECLARE @.name as varchar(255)
> OPEN table_names
> FETCH NEXT FROM table_names INTO @.name
> WHILE (@.@.FETCH_STATUS <> 1)
> SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
> --PRINT @.cmd
> EXEC @.cmd
> FETCH NEXT FROM table_names INTO @.name
> DEALLOCATE table_names
> CLOSE table_names
Infinite loop. Your loop doesn't include the FETCH NEXT. Also you should
test for @.@.FETCH_STATUS = 0, since values other that 1 are possible.
Should beL
DECLARE @.cmd as varchar(255)
DECLARE table_names CURSOR FOR
SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
DECLARE @.name as varchar(255)
OPEN table_names
FETCH NEXT FROM table_names INTO @.name
WHILE @.@.FETCH_STATUS = 0
BEGIN
SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
--PRINT @.cmd
EXEC @.cmd
FETCH NEXT FROM table_names INTO @.name
END
CLOSE table_names
DEALLOCATE table_names
David|||Thanks David
"David Browne" wrote:
>
> "brymer28303" <brymer28303@.discussions.microsoft.com> wrote in message
> news:D3BA7C42-13A0-49EF-A476-3A32121E2D41@.microsoft.com...
> >I have this procdure to grant select permission to a developers group on an
> > SQL Databse. The query executes but never returnes and the permissions
> > are
> > set. Can anyone tell me why the little world keeps spinning and never
> > returns. thanks
> >
> > DECLARE @.cmd as varchar(255)
> >
> > DECLARE table_names CURSOR FOR
> > SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
> > DECLARE @.name as varchar(255)
> >
> > OPEN table_names
> > FETCH NEXT FROM table_names INTO @.name
> > WHILE (@.@.FETCH_STATUS <> 1)
> > SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
> > --PRINT @.cmd
> > EXEC @.cmd
> > FETCH NEXT FROM table_names INTO @.name
> > DEALLOCATE table_names
> > CLOSE table_names
> Infinite loop. Your loop doesn't include the FETCH NEXT. Also you should
> test for @.@.FETCH_STATUS = 0, since values other that 1 are possible.
> Should beL
> DECLARE @.cmd as varchar(255)
> DECLARE table_names CURSOR FOR
> SELECT [name] FROM sysobjects WHERE type = 'u' ORDER BY [name]
> DECLARE @.name as varchar(255)
> OPEN table_names
> FETCH NEXT FROM table_names INTO @.name
> WHILE @.@.FETCH_STATUS = 0
> BEGIN
> SELECT @.cmd = 'GRANT SELECT ON ' + @.name + ' TO [VS Developers]'
> --PRINT @.cmd
> EXEC @.cmd
> FETCH NEXT FROM table_names INTO @.name
> END
> CLOSE table_names
> DEALLOCATE table_names
>
> David
>sql
Granting Permissions to a stored procedure
I have a stored procedure sp_LogError that it self executes the
xp_cmdShell procedure.
When I execute the procedure using a 'normal' acount with only public
acces to the database i get an error:
EXECUTE permission denied on object 'xp_cmdshell', Database 'master',
owner 'dbo'
sp_LogError is owned by dbo and all users have permission to access it.
It runs fine under the sa account.
What do I need to do so that all users can execute sp_LogError without
granting all users access to xp_cmdShell.
Thanks In Advance
MalachyHi,
You need to give exclusive previlage to xp_cmdshell proc to user if he is
not the member of sy
min role.
Execute permissions for xp_cmdshell default to members of the symin fixed
server role, but can be granted to other users.
Note:
If you choose to use a Windows NT account that is not a member of the local
administrator's group to start MSSQLServer service, users who
are not members of the symin fixed server role cannot execute xp_cmdshell
Thanks
Hari
SQL Serber MVP
"Malachy O'Connor" <malachyoconnor2@.o2.ie> wrote in message
news:1113392109.360561.53050@.g14g2000cwa.googlegroups.com...
>I have a stored procedure sp_LogError that it self executes the
> xp_cmdShell procedure.
> When I execute the procedure using a 'normal' acount with only public
> acces to the database i get an error:
> EXECUTE permission denied on object 'xp_cmdshell', Database 'master',
> owner 'dbo'
> sp_LogError is owned by dbo and all users have permission to access it.
> It runs fine under the sa account.
> What do I need to do so that all users can execute sp_LogError without
> granting all users access to xp_cmdShell.
> Thanks In Advance
> Malachy
>|||Thanks for that Hari.
It is just that I was hoping not to have to give access to xp_cmdshell
to all users that wished to use my sp. I|||I was able to create my own sp_logError in master which called the
xp_cmdShell. Because it was owned by dbo it had permission to execute
xp_cmdShell.
I was then able to make sp_logError public so everyone can access it
without needing explicit access to xp_cmdShell.
xp_cmdShell procedure.
When I execute the procedure using a 'normal' acount with only public
acces to the database i get an error:
EXECUTE permission denied on object 'xp_cmdshell', Database 'master',
owner 'dbo'
sp_LogError is owned by dbo and all users have permission to access it.
It runs fine under the sa account.
What do I need to do so that all users can execute sp_LogError without
granting all users access to xp_cmdShell.
Thanks In Advance
MalachyHi,
You need to give exclusive previlage to xp_cmdshell proc to user if he is
not the member of sy
min role.Execute permissions for xp_cmdshell default to members of the sy
min fixedserver role, but can be granted to other users.
Note:
If you choose to use a Windows NT account that is not a member of the local
administrator's group to start MSSQLServer service, users who
are not members of the sy
min fixed server role cannot execute xp_cmdshellThanks
Hari
SQL Serber MVP
"Malachy O'Connor" <malachyoconnor2@.o2.ie> wrote in message
news:1113392109.360561.53050@.g14g2000cwa.googlegroups.com...
>I have a stored procedure sp_LogError that it self executes the
> xp_cmdShell procedure.
> When I execute the procedure using a 'normal' acount with only public
> acces to the database i get an error:
> EXECUTE permission denied on object 'xp_cmdshell', Database 'master',
> owner 'dbo'
> sp_LogError is owned by dbo and all users have permission to access it.
> It runs fine under the sa account.
> What do I need to do so that all users can execute sp_LogError without
> granting all users access to xp_cmdShell.
> Thanks In Advance
> Malachy
>|||Thanks for that Hari.
It is just that I was hoping not to have to give access to xp_cmdshell
to all users that wished to use my sp. I|||I was able to create my own sp_logError in master which called the
xp_cmdShell. Because it was owned by dbo it had permission to execute
xp_cmdShell.
I was then able to make sp_logError public so everyone can access it
without needing explicit access to xp_cmdShell.
Friday, March 23, 2012
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?
>
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?
>
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
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
Subscribe to:
Posts (Atom)