InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comThu, 23 May 2013 14:38:07 GMT20http://www.sqlservercentral.com/Forums/Topic640254-359-1.aspx-- Create a new role CREATE ROLE SP_Fn_executor-- Grant execute to the created roleGRANT EXECUTE TO SP_Fn_executor The above statement would create a role and grant execute permission on all existing stored procedures and scalar functions.And as when we create new ones the permission would automatically be given to the Role.Tue, 19 Oct 2010 23:25:17 GMTsantosh_mahajanhttp://www.sqlservercentral.com/Forums/Topic640254-359-1.aspxIn SQL Server 2005 you can define the execution context of the following user-defined modules: functions (except inline table-valued functions), procedures, queues_________________[url=http://www.microsoftoffice-2010.com/] Download Microsoft 2010 [/url] Sat, 23 Jan 2010 09:08:50 GMTrojen83http://www.sqlservercentral.com/Forums/Topic640254-359-1.aspxEasy way to give users/developers view permission to Stored Procedures in SQL 2005:USE AdventureWorksGO CREATE PROCEDURE usp_ExecGrantViewDefinition (@login VARCHAR(30)) AS /* Included Object Types are: P - Stored Procedure V - View FN - SQL scalar-function TR - Trigger IF - SQL inlined table-valued function TF - SQL table-valued function U - Table (user-defined) */ SET NOCOUNT ON CREATE TABLE #runSQL (runSQL VARCHAR(2000) NOT NULL) --Declare @execSQL varchar(2000), @login varchar(30), @space char (1), @TO char (2) DECLARE @execSQL VARCHAR(2000), @space CHAR (1), @TO CHAR (2) SET @to = 'TO' SET @execSQL = 'Grant View Definition ON ' SET @login = REPLACE(REPLACE (@login, '[', ''), ']', '') SET @login = '[' + @login + ']' SET @space = ' ' INSERT INTO #runSQL SELECT @execSQL + schema_name(schema_id) + '.' + [name] + @space + @TO + @space + @login FROM sys.all_objects s WHERE type IN ('P', 'V', 'FN', 'TR', 'IF', 'TF', 'U') AND is_ms_shipped = 0 ORDER BY s.type, s.name SET @execSQL = '' Execute_SQL: SET ROWCOUNT 1 SELECT @execSQL = runSQL FROM #runSQL PRINT @execSQL --Comment out if you don't want to see the output EXEC (@execSQL) DELETE FROM #runSQL WHERE runSQL = @execSQL IF EXISTS (SELECT * FROM #runSQL) GOTO Execute_SQL SET ROWCOUNT 0 DROP TABLE #runSQL GO Once this procedure has been created you can grant the permissions as follows. This example grants view definition to a user "XYZ" in "Adventureworks" Database for all object types that were selected.USE AdventureworksGO EXEC usp_ExecGrantViewDefinition 'XYZ' GO Thu, 21 Jan 2010 10:04:31 GMTPrakash.Bhojegowdahttp://www.sqlservercentral.com/Forums/Topic640254-359-1.aspxBrian, I like this way better than my idea..:-)Wed, 21 Jan 2009 08:33:58 GMTRoy Ernesthttp://www.sqlservercentral.com/Forums/Topic640254-359-1.aspxEven db_ddladmin is overkill.Grant CREATE PROC to a role. Put developers in that role.Grant ALTER SCHEMA on the schema(s) that the developers need to modify stored procedures in to the role.Grant VIEW DEFINITION on the schema(s) that the developers need to modify stored procedures in to the role.See if that does the job.Wed, 21 Jan 2009 08:28:23 GMTK. Brian Kelleyhttp://www.sqlservercentral.com/Forums/Topic640254-359-1.aspxI agree, they will have view only access to any production objects. It has been difficult finding the right balance to allow development and debugging without giving too much permission. Thank you for responding!kayWed, 21 Jan 2009 07:03:00 GMTkwilthttp://www.sqlservercentral.com/Forums/Topic640254-359-1.aspxI think even a db_owner is an overkill. What I would suggest is to create a Role with the ddl_Admin as the rights to that particular DB and add the developers who need access to compile Stored procs to that role.If I was in your shoes, I would never give a Developer access to even read data (forget compiling Stored proc :exclamationmark: ) to a developer in the production Environment.Wed, 21 Jan 2009 06:59:13 GMTRoy Ernesthttp://www.sqlservercentral.com/Forums/Topic640254-359-1.aspxMoved to SS2005 forumI tend to agree with Markus' advice.Don't grant this advice to public, however, create your own role.Wed, 21 Jan 2009 03:54:08 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic640254-359-1.aspxFirst of all I think you will get better response if you post a 2005 question in the appropriate forum.Now to your question. There are a couple od roles which by default can view properties of a stored procedure. Sysadmin will work, but is total overkill. db_owner or ddl_admin would be a much better choice. GRANT VIEW DEFINITION will also work.But keep in mind that it's not possible to grant any this permission on one specific procedure. The grantee will be able to see definition and properties of all database objects. Wed, 21 Jan 2009 03:32:52 GMTMarkusBhttp://www.sqlservercentral.com/Forums/Topic640254-359-1.aspxGenerally, SPs need to be given EXEC permission for those who need to run the SPs.For this, permission will be provided after creating / altering the SPs likeGRANT EXEC on - Here PUBLIC can be used to provide EXEC permission to ALL who have access permission to the DB / Server.You can give the specific permission for the User using:GRANT Wed, 21 Jan 2009 02:29:40 GMTSuresh.Uthamhttp://www.sqlservercentral.com/Forums/Topic640254-359-1.aspxOn a development server, we have users who need to be able to modify, execute and view properties of stored procedures. I have tried combinations of permissions such as Alter, Control and View but when they try to view the properties, they receive the following error message:Property Default Schema is not available for Database "[database_name]". This property may not exist for the object, or may not be retrievable due to insufficient access rights.Is there some combination aside from sysadmin that allows viewing stored procedure properties?Tue, 20 Jan 2009 14:32:21 GMTkwilt