If we have an alter table statement within a stored procedure. Will it just affect that session or will it affect all sessions?
We use the alter table to disable the triggers that occur because we don't want them run when the stored procedure occurs but want the update triggers to run at all other times.
Cheers,
"Alter table" is an DDS operation - it will change the DB structure for all connections.
Here is a trick: create temp table with unique name like #no_triggers_for_[procname] at the beginning of your sp and check for it's existence within triggers.
Related
Is there a way to have a SQL Server stored procedure trigger a query without editing the stored procedure code?
I am looking for a way to do something along the lines of a CREATE TRIGGER, but have it be triggered by a stored procedure instead of table update without altering the original code for the stored procedure.
I would create a trigger for when the table updates, but the stored procedure that updates the table updates it tens of thousands of times, so that is unfeasible.
select * from sys.dm_exec_procedure_stats
I would check the "execution_count" to the system table listed above. You can create a stored procedure and then create a job that runs that stored procedure at a specified interval.
I have a stored procedure to run after a set of tables, all belonging to the same schema [DATA_Countries], is dropped and then re-inserted.
The operation is performed by another application, which drops and recreates the target table, over which I have no control.
Since the table is dropped and recreated each time, I can not use triggers on each target table.
Is there a way to get a trigger for each time a table is inserted into a specific schema, to return the name of such table and launch a parametrized stored procedure?
Thanks!
Yes, You can create DDL Triggers on SQL Server to track the DDL Changes. For example, If I want to track the changes in Stored Procedures on my Database AdventureWorks, I can create a trigger like this
CREATE TRIGGER td_ProcTrack
ON AdventureWorks
FOR CREATE_PROCEDURE, ALTER_PROCEDURE, DROP_PROCEDURE
AS
BEGIN
<my code>
END
Refer this Article for more detailed examples
suppose i am calling a Stored Procedure and sending some params. the Stored Procedure will update a table and a trigger is there for that table. so when Stored Procedure update table then i want which user is updating the table but i am not using sql server user name rather i will send user names to SP who will update the table. so before update i can store that user name in local temp table and query that local temp table from trigger to get that user name. i hope it is possible but i want to other good option to achieve this job. so please share idea. thanks
You can encode the user name in the procedure into the session using SET CONTEXT_INFO
This can be read in the trigger by CONTEXT_INFO
This is concurrency safe: each session/call is isolated from any other.
And no need for a temp table or such.
DECLARE #context varbinary(100) = CAST('foobar' AS varbinary(100));
SET CONTEXT_INFO #context;
SELECT CAST(CONTEXT_INFO() AS varchar(100));
I need to alter a trigger in SQL Server. After I am doing, do I just execute the trigger similar to how I would do for a Stored Procedure?
ALTER TRIGGER
Yes, that is right, just use ALTER. If you right-click on your trigger in Object Explorer in SSMS and select Script Trigger as/ALTER To, you will see the ALTER statement created for your trigger.
ALTER TRIGGER triggerName
ON tableName
FOR INSERT -- or update & delete
AS
-- sql here
http://msdn.microsoft.com/en-us/library/ms176072.aspx
You don't "execute" a trigger. Triggers are "triggered" at certain points depending upon your definition of them.
For example an AFTER UPDATE trigger would run for all rows updated after you send an UPDATE command to the table on which the trigger is created.
I have a SQL Server 2008 database where all access to the underlying tables is done through stored procedures. Some stored procedures simply SELECT records from the tables while others UPDATE, INSERT, and DELETE.
If a stored procedure UPDATES a table does the user executing the stored procedure also need UPDATE permissions to the affected tables or is the fact that they have EXECUTE permissions to the stored procedure enough?
Basically I am wondering if giving the user EXECUTE permissions to the stored procedures is enough or do I need to give them SELECT, UPDATE, DELETE, and INSERT permissions to the tables in order for the stored procedures to work. Thank you.
[EDIT] In most of my stored procedures it does indeed appear that EXECUTE is enough. However, I did find that in stored procedures where "Execute sp_Executesql" was used that EXECUTE was not enough. The tables involved needed to have permissions for the actions being performed within "sp_Executesql".
Permissions on tables are not checked (including DENY) if tables and proc have the same owner. They can be in different schemas too as long as the schemas have the same owner.
See Ownership chaining on MSDN
Edit, from a comment from a deleted answer.
The context is always the current login unless EXECUTE AS as been used: only referenced object DML permissions are not checked. Try OBJECT_ID(referencedtable) in a stored proc where no rights are assigned to referencedtable. It gives NULL. If executed by the owner of the stored proc then it would give a value because owener has rights on referencedtable
Execute permissions on the stored procedure is sufficient.
CREATE TABLE dbo.Temp(n int)
GO
DENY INSERT ON dbo.Temp TO <your role>
GO
CREATE PROCEDURE dbo.SPTemp(#Int int)
AS
INSERT dbo.Temp
SELECT #Int
GO
GRANT EXEC ON dbo.SPTemp TO <your role>
GO
Then the (non-db_owner) user will have the following rights:
EXEC dbo.SPTemp 10
GO
INSERT dbo.Temp --INSERT permission was denied on the object 'Temp'
SELECT 10
However, if there is dynamic SQL inside dbo.SPTemp that attempts to insert into dbo.Temp then that will fail. In this case direct permission on the table will need to be granted.
Maybe you can use
"with execute as owner"
when you create the stored procedure, such as below:
create procedure XXX
with execute as owner
as
begin
...
end
go
Then you only need to grant the user the EXECUTE permission for the stored procedure XXX.
Execute permission on a stored procedure that does an insert, update, or delete is sufficient. You do not need to grant those permissions at the table level. In fact, I would discourage that approach. Using a stored procedure gives you more control over how the change occurs. For instance, you may wish to do some checking prior to allowing the update. Using a stored procedure can also help prevent major accidents--like deleting all the rows in the table because someone forgot the WHERE clause!
THANK YOU SO MUCH! I had a similar problem. This lead me to the answer.
I was attempting to trunctate a table in a stored procedure that called other stored procedures that were nested in IF statements.
My error was
The server principal "domain\my_id" is not able to access the database "2nd_DB" under the current security context.
I had given the calling stored procedure rights to do the truncate (EXECUTE AS SELF), which then caused a problem because SELF didn't have rights to the 2nd DB. Our solution was to move the truncate to another SP, include the EXECUTE AS SELF. We now call the truncate SP, execute our data processing, make logic determination, and call the appropriate 3rd SP.