I have created a stored procedure using SQL Server Management studio.
I am able to create it but if I tryto right click on the stored procedure and execute it, I am getting permission denied error# 229.
I have administrator rights. How can I execute this procedure.
if you are really connecting as sa this should not happen, if you are not, could be that your user does not really have all the rights.
It is also difficult to understand the problem without seeing the body of the stored in case you are doing anything special in there.
at this link anyway: http://www.sqlservercentral.com/Forums/Topic463688-146-1.aspx somebody was discussing the same error and there are some SQL commands scrolling down the page where some people claim to have fixed the issue.
Are you sure that you have sufficient permissions?
Error 229 means that you don't.
Your user needs at least EXECUTE permissions for the stored procedure:
Stored Procedure and Permissions - Is EXECUTE enough?
Here's how you can check if you have the permission:
MS SQL Server: Check to see if a user can execute a stored procedure
Verify that you didn't add your user to any of the deny roles, like db_denydatareader.
Use this to add execute privillages to your SQL Login:
GRANT EXECUTE ON SPNAME TO UserName;
GO
Related
User with db_reader would like to get execute permission on stored procedure that contains INSERT and TRUNCATE statements against existing tables.
Just to see I granted what was requested, but it seems like it doesn't work.
Is such mix of permissions doable?
EDIT: I granted permissions on sp using this:
use [dbName]
GO
GRANT EXECUTE ON [dbo].[spFront_ProcedureName] TO [ABC\serviceAccount]
GO
Granting EXECUTE permission on the Stored Procedure allows the user to call the procedure.
However, depending upon what the procedure does, it may still not do as you expect. Specifically around TRUNCATE, see the info at this link which identifies that additional permission may be needed to use TRUNCATE unless the procedure is carefully crafted.
The specific error message may help identify whether the issue arises from this or if it is from ownership chaining.
I have created a procedure in different database than the user used to create it,
The user I used to create the procedure is like 'vbhas' and the database it is created is like 'IFSRD', when I login as 'vbhas' and try to execute the proc it gives the error, could you please let me know how to modify the execute access so that I will be able to execute this procedure successfully?
Thanks
You have to add the SECURITY option. Depending on the SQL in the SP and your needs this might be SECURITY CREATOR|OWNER|INVOKER instead of the default DEFINER.
You should read the manuals for details
Thanks dnoeth...
Got to know that Teradata gives permissions at database level, so now I created the procedure in the database which has execute permissions to all objects.
I need run .dtsx packages mounted in SSIS catalog with parameters, throught an stored procedure, because one aplication fired dtsx using stored procedure with parameter values
I have created the stored procedure using
SSISDB.Catalog.Create_Execution
Set_Execution_Parameter_Value and
Start_Execution.
This works, but for run the user need have db_owner privilegies on principal_db and ssis_admin on SSISD this will only run if the executing user is a windows account, no problem with this but I need the windows account have minimal rigths on principal_db, I know I can't do it using Sql user because is necesary an windows account but when I create my procedure give execution permition for execute stored proc to an win user in the principal database, create the win user on SSISDB and give permision on catalog procedures
SSISDB.Catalog.Create_Execution
Set_Execution_Parameter_Value
Start_Execution
and add to my stored procedure the clause "execute as owner",show me next error
I tried using Execute As and specifying a windows account but I get the error
The current security context cannot be reverted. Please switch to the
original database where 'Execute As' was called and try it again.
I tried using "execute as self" and when I try run the procedure with another win user (that give permision) show me is necesary windows account.
My user has permision on
db_owner
sysadmin and
ssis_admin
I think I need come into my permissions to an user for execute this, considering that my procedure working with 2 databases principal_db (where record my procedure) and SSISDB (where live the catalog procedures for create execution and put parameters).
Somebody can help me?
SSIDB admin permission required to run DTSX package.
Package references DB2 proc, needing DBO so proc MUST have EXECUTE as OWNER
AND Proc has GRANT Execute to Win User
Schedule job step owned by WIN USER... this so? and fails?
I want to set a readony permission to a database user.
This user should have permission to execute stored procedures
But this user should not have permission to update or inser or alter anything in database through these stored procedures or through any methord
can anyone help please
Simply don't grant permission on the stored procs that change data.
Otherwise, you could use triggers on the tables to check, but that's a bit silly compared to using permissions correctly
Note: ownership chaining means that permissions on tables won't be checked, even DENY, so this won't work.
Yes. Set the EXECUTE permission for that user, then they'll only be able to execute the Stored Procedures in your database.
GRANT EXECUTE ON dbo.storedprocedurename TO SQLUSERNAME;
You'll need to set the permissions on a procedure by procedure basis. Give them permission to stored procedures that select, and don't give them permission to the stored procedures that do updates or inserts.The best way is to setup roles, and add the users to the roles.
This is pretty flexible and you can use it to restrict exactly what uses can do. For example, it may actually be okay for them to update a table as long as they do it through a certain stored procedure. To do this you can deny them all permission to that table, but grant them permission to execute the stored proc.
give execute permission on the proc and make sure the user doesn't have write access to the tables used by the proc. Check if he is not member of the db_datawriter roled.
If you want to be 100% sure, add the user to the db_denydatawriter role
I have a database where all access is controlled by stored procedures. The DBA would like to avoid giving users direct read/write access to the underlying tables, which I can understand. Hence all updating and selecting of data is done via stored procedures. Basically he has created one role that has EXECUTE permissions to all the stored procedures in the database and given users that role.
The problem is that one of the stored procedures dynamically builds a SQl Query and executes it via "Execute sp_Executesql". Without going into great detail the query is built dynamically because it changes significantly depending on many user input parameters. The stored procedure in question is only a SELECT sql statement however I am finding that just giving the stored procedure EXECUTE permission is not enough. The underlying tables referenced within the stored procedure that make use of "Execute sp_Executesql" need to have been given "datareader" access or else the stored procedure fails.
Any thoughts on how to correct this? I really wanted to restrict access to the tables to only stored procedures, but I need to find a way to work around the stored procedures that make use of "Execute sp_Executesq"l. Thank you.
In the wrapper proc you can use EXECUTE AS OWNER or EXECUTE AS SomeuserWithNoLogin
This will change the login context for the duration of the stored proc which includes sp_executesql.
If you use OWNER, it will work because you're already using ownership chaining.
If your DBA (good man!) does not want you running as dbo, then set up a user that has full read but no rights. EXECUTE AS <user> requires an entry is sys.database_principals
Like this:
CREATE USER SomeuserWithNoLogin WITH WITHOUT LOGIN
EXEC sp_addrolemember 'db_datareader', 'SomeuserWithNoLogin'
For more info, see EXECUTE AS Clause on MSDN and CREATE PROCEDURE
The real problem is that sp_Executesql is in the master database, not necessarily the database your working in. Your DBA has to give execute sp_Executesql permission to the calling procedure. Than anyone who has permission to call that procedure will be able to run the sp_Executesql.