There is a context menu in MSSQL - Script Stored Procedure as -> DROP and CREATE
But when I am generating procedure, it do not contain existing GRANT EXECUTE role.
How can I add (automatically!) it to generating script?
In SSMS, go to Tools, Options, SQL Server Object Explorer, Scripting and in the Object Scripting Options section, change Script Permissions to True.
Related
I have created a user with database roles db_datareader, db_datawriter and public. Also I have configured with server roles as public.
Now this user cannot view the list of stored procedure when clicking on stored procedures node in objects explorer. How can I assign permission to see and execute all the stored procedures? I want to do this through SSMS without launching any command.
I am using SQL Server 2012 and below versions:
Microsoft SQL Server Management Studio 11.0.2100.60
Microsoft Data Access Components (MDAC) 10.0.17763.1
Microsoft MSXML 3.0 4.0 5.0 6.0
Microsoft Internet Explorer 9.11.17763.0
Microsoft .NET Framework 4.0.30319.42000
Sistema operativo 6.3.17763
Looks like you can do this, though not as "simple" as you would expect.
I would, personally create a database role to do this. Go to your database in the Object explorer, and expand the Security Folder. Then right click Roles and Select New -> New Database Role.
Give the Role a name (I'll use db_executor) on the General Pane and then go to the Securables Pane. Click Search... at the top and select the radio option Specific Objects... and click OK. Click Object Types... and then tick Databases and then OK. Now click Browse... and tick the database you are adding the role to, then click OK and then OK.
In the datagrid at the bottom locate the Permission Execute, and tick the box in the column Grant. Then OK. This will run the below SQL on your instance:
USE [YourDatabase]
GO
CREATE ROLE [db_executor]
GO
use [YourDatabase]
GO
GRANT EXECUTE To [db_executor]
GO
Yes, Microsoft really is inconsistent with the casing of USE for that statement, and it omits the ; in it's commands.
Now you have created the role, locate the user you want to give access to in the object explorer in the Users folder. Right Click them and select Properties. Go to the Membership Pane and tick the box next to db_executor. Then click OK. This will run the below SQL on your instance:
USE [YourDatabase]
GO
ALTER ROLE [db_executor] ADD MEMBER [YourUser]
GO
Of course, why you wouldn't just run the 2 above commands, which is far quicker, I do not know.
I don't think there's a graphical way of doing this within the UI, but you can create a new query window in SSMS and execute one of these queries.
For a particular role you can:
/* GRANT EXECUTE TO THE ROLE */
GRANT EXECUTE TO role_what_needs_permissions
For a user
USE [the_database]
GO
GRANT EXECUTE TO [the_user]
I am using Visual Studio 2017 with SSDT and am attempting to sync a SQL Server 2014 database in an upper environment with objects from a DEV database. The problem is, schema compare generates all permission updates with "AS [dbo]" at the end:
GRANT EXECUTE ON OBJECT::[dbo].[uspMyStoredProc] TO [rolMyRole]
AS [dbo];
GO
I do not have permission to sync the DB with the "AS [dbo]" statement at the end of each GRANT but can run each of the GRANTs without this statement. Is there any way to exclude this statement in the UPDATE script?
I seek a T-SQL script that selects all permissions for all users in an Azure SQL Database. In particular I want to generate permission grant/revoke/deny statements for all Views, UDFs and Stored Procs to recreate these permissions in an on-prem database.
One way to list the permissions scripts is to include them with the View, SPROC, and UDF definitions produced via the Generate Scripts... context menu option in SSMS. On the Set Scripting Options tab of the Generate and Publish Scripts wizard, click the Advanced button and set the Script Object-Level Permissions option to True.
is there a way to check, if a field in a table is set by a procedure in Sybase Anywhere v12?
If you have access to Sybase Central as DBA or as the procedure owner you can SQL for the procedure.
From the documentation:
Use the SQL Anywhere 12 plug-in to connect to the database as a user with DBA or Resource authority.
In the left pane, double-click Procedures & Functions.
Select the procedure.
Use one of the following methods to edit the procedure:
In the right pane, click the SQL tab.
Right-click the procedure and click Edit In New Window.
I recently did an import of database from a sql server 2000 database to a sql server 2005 database. I've gone through and setup what I thought were the same login credentials and owner permissions that I had previously setup in my old database.
All of the code base I'm working has stored procedures listed simply by stored procedure name.
In order to make sure I have the proper logins created, I am logging into the SQL Server Management studio with the connection information my application is using (i.e. using the username "licensemgr" and it's associated password). I can see all the tables, stored procedures, etc... in my database when I log in with combination. When I try to run a stored procedure, Sql Server Management Studio uses the following syntax to execute it:
EXEC: #return_value = [licensemgr].[Stored_Procedure_Name]
and it executes without error.
If I try to remove the [licensemgr]. from before the [Stored_Procedure_Name], however I get the error "Cannot find stored procedure: Stored_Procedure_Name". This is the same error I get when running my application off this database. I changed one stored procedure call in my application to have "licensemgr." in front of the stored procedure name and that seemed to correct the problem, however, I don't want to do that for each and every stored procedure call in my application. I am therefore wondering what type of setup / permissions type issue I might be missing in my SQL Server instance so that even when I'm logged into the database as licensemgr, I cannot see the stored procedure which is in the schema "licensemgr".
In SQL server 2000 the [licensemgr] referred to the owner of the table. So when you are logged in as [licensemgr] you do not need the prefix.
In SQL Server 2005 this has been changed to the schema, therefore it must be specified. See:
http://msdn.microsoft.com/en-us/library/ms190387.aspx
EDIT
There are two things that you need to watch out for:
If the user is in the sysadmin role, he will always default to the dbo schema, therefore you need to prefix
If your user needs to run code that is in different schemas you will need to prefix
If none of the two above it should work by setting the default schema for the user
When you created your user, did you specify DEFAULT_SCHEMA?
CREATE USER ... WITH DEFAULT_SCHEMA = "licensemgr"
If not, you may need to use ALTER USER to fix this for your user in the new system.