I have the following trigger:
USE SomeDB
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER TRIGGER [Staging].[RunPivot15]
ON [Staging].[UriData]
AFTER INSERT, UPDATE
AS
BEGIN
SET NOCOUNT ON
EXEC [Staging].[PivotData]
END
It will not fire. The table concerned receives about 30 rows every five minutes. From that point I am stuck. I have been reading that because more than one row is being inserted I have to run a cursor. I have tried the cursor and cannot get that to work either.
Can you advise what the best approach here is?
TIA
It's highly unlikely the trigger to not run. Add a couple of print statements around the procedure call in your trigger, eventually in your stored procedure too. This will help you to trace the execution when you run an update statement in Management Studio to fire the trigger.
USE SomeDB
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER TRIGGER [Staging].[RunPivot15]
ON [Staging].[UriData]
AFTER INSERT, UPDATE
AS
BEGIN
SET NOCOUNT ON
PRINT 'Before call.'
EXEC [Staging].[PivotData]
PRINT 'After call.'
END
Then run an update statement in Management Studio and check Messages tab to see is your messages printed.
update Staging.RunPivot15 set SomeColumn = SomeColumn where SomeColumn = SomeValue
No, you do not need cursors. When your trigger is executed, if more than one row is affected, there will be multiple rows in inserted / deleted pseudo tables too. In your case you do not read which rows are updated either, so just run the procedure. If you need to know which rows exactly are modified, then write code to process them in set-based approach (all rows at once). Looping with cursors is practically never good idea in the database.
Related
I have a scenario where certain users must have the rights to update or delete certain records in production. What I want to do put in a safeguard to make sure they do not accidentally update or delete a large section (or entirety) of the table, but only a few records as per their need. So I wrote a simple trigger to accomplish this.
CREATE TRIGGER delete_check
ON dbo.My_table
AFTER UPDATE,DELETE AS
BEGIN
IF (SELECT COUNT(*) FROM Deleted) > 15
BEGIN
RAISERROR ('Bulk deletes from this table are not allowed', 16, 1)
ROLLBACK
END
END --end trigger
But here is the problem. There is a stored procedure that can do bulk updates to the table. The users can and should be allowed to call the stored procedure, as it's scope is more constrained. So my trigger would unfortunately preclude them from calling the stored proc when they need to.
The only solution I have thought of is to run the stored proc as an impersonated user, then modify the trigger to exclude that user from the logic. But that will bring up other issues in my environment. Not unsurmountable, but annoying. Nevertheless, this seems the only viable option.
Am I thinking about this the right way, or is there a better approach?
You can add a check of ##NESTLEVEL in the trigger. The value will be 1 for an ad-hoc statement or 2 when called from the stored procedure.
CREATE TRIGGER delete_check
ON dbo.My_table
AFTER UPDATE,DELETE AS
BEGIN
IF (SELECT COUNT(*) FROM Deleted) > 15
AND ##NESTLEVEL = 1 --ad-hoc delete
BEGIN
RAISERROR ('Bulk deletes from this table are not allowed', 16, 1);
ROLLBACK;
END;
END;
I usually handle this with CONTEXT_INFO(). This gives you a better control than ##NESTLEVEL because you can actually identify the specific stored procedure doing the calling and handle them individually if required. You do this as follows:
Add the procedure name to CONTEXT_INFO() e.g.
-- START OF STORED PROCEDURE
-- Tell the trigger who we are, and that we can be trusted.
declare #OldContext char(128), #NewContext varbinary(128);
-- Get existing context_info()
set #OldContext = coalesce(convert(char(128), context_info()), '');
-- Add new info to context_info
set #NewContext = convert(varbinary(128),convert(char(128), 'dbo.MyProcedureName'));
-- Store new context info
set context_info #NewContext;
-- STORED PROCEDURE CONTENT
-- END OF STORED PROCEDURE
-- Restore context_info
set #NewContext = convert(varbinary(128), #OldContext);
set context_info #NewContext;
In the trigger return early if the CONTEXT_INFO() is from a trusted source e.g.
-- START OF TRIGGER
declare #NewContext char(128) = coalesce(convert(char(128),context_info()),'');
if #NewContext in ('dbo.MyProcedureName') begin
return;
end;
Another advantage of this approach (for other trigger uses) is you can avoid carrying out logic in a trigger when called from a SP. Because often you put logic in a trigger to ensure that it happens regardless of how the insert/update/delete happens. But when done in an SP you can ensure the required logic is carried out within the SP which avoids the need to do it in a trigger. Especially useful if you end up with performance issues due to too much logic in the trigger.
Note: For SQL Server 2016+ you can use SESSION_CONTEXT() in a similar way.
One way of doing this would be:
Create a stored procedure to perform the desired work
If the criteria varies greatly, create several procedures for each "kind" of work
Grant EXECUTE permissions to the desired users on those procedures ("kind of work") that they are permitted to do. (You are using Database Roles and Domain Groups, right?)
Revoke permissions to make ad hoc data modifications on the table
It can be fussy to set up, but it supports the "Principle of Least Permissions", permitting users to do only what they are supposed to do.
I am using Microsoft SQL server. the following code works if run from a QUERY:
SELECT *
INTO mydatabase.dbo.atable
FROM linkedserver.sandbox.dbo.atable
but it does not if inserted into a stored procedure:
SET ANSI_NULLS ON GO
SET QUOTED_IDENTIFIER ON GO
ALTER PROCEDURE dataMigration
AS BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
-- Insert statements for procedure here
SELECT *
INTO mydatabase.dbo.atable
FROM linkedserver.sandbox.dbo.atable
END
GO
Command(s) completes successfully but no table is created into mydatabase. Sorry for the trivial question. I had a look at similar issues but i did not find a case similar to mine.
Thank you for your help.
You have to execute the stored Procedure after you run the code to alter it.
try running:
exec dataMigration
Right clickOption Image the store procedure and click "Execute Store procedure"
I need to provide an auto update feature to my application.
I am having problem in applying the SQL updates. I have the updated SQL statement in my .sql file and what i want to achieve is that if one statment fails then entire script file must be rolled back
Ex.
create procedure [dbo].[test1]
#P1 varchar(200),
#C1 int
as
begin
Select 1
end
GO
Insert into test (name) values ('vv')
Go
alter procedure [dbo].[test2]
#P1 varchar(200),
#C1 int
as
begin
Select 1
end
GO
Now in the above example, if i get the error in third statement of "alter procedure [dbo].[test2]" then i want to rollback the first two changes also which is creating SP of "test1" and inserting data into "test" table
How should i approach this task? Any help will be much appreciated.
If you need any more info then let me know
Normally, you would want to add a BEGIN TRAN at the beginning, remove the GO statements, and then handle the ROLLBACK TRAN/COMMIT TRAN with a TRY..CATCH block.
When dealing with DML though there are often statements that have to be at the start of a batch, so you can't wrap them in a TRY..CATCH block. In that case you need to put together a system that knows how to roll itself back.
A simple system would be just to backup the database at the start and restore it if anything fails (assuming that you are the only one accessing the database the whole time). Another method would be to log each batch that runs successfully and to have corresponding rollback scripts which you can run to put everything back should a later batch fail. This obviously requires much more work (writing an undo script for every script PLUS fully testing the rollbacks) and can also be a problem if people are still accessing the database while the upgrade is happening.
EDIT:
Here's an example of a simple TRY..CATCH block with transaction handling:
BEGIN TRY
BEGIN TRANSACTION
-- All of your code here, with `RAISERROR` used for any of your own error conditions
COMMIT TRANSACTION
END TRY
BEGIN CATCH
ROLLBACK TRANSACTION
END CATCH
However, the TRY..CATCH block cannot span batches (maybe that's what I was thinking of when I said transactions couldn't), so in your case it would probably be something more like:
IF (OBJECT_ID('dbo.Error_Happened') IS NOT NULL)
DROP TABLE dbo.Error_Happened
GO
BEGIN TRANSACTION
<Some line of code>
IF (##ERROR <> 0)
CREATE TABLE dbo.Error_Happened (my_id INT)
IF (OBJECT_ID('dbo.Error_Happened') IS NOT NULL)
BEGIN
<Another line of code>
IF (##ERROR <> 0)
CREATE TABLE dbo.Error_Happened (my_id INT)
END
...
IF (OBJECT_ID('dbo.Error_Happened) IS NOT NULL)
BEGIN
ROLLBACK TRANSACTION
DROP TABLE dbo.Error_Happened
END
ELSE
COMMIT TRANSACTION
Unfortunately, because of the separate batches from the GO statements you can't use GOTO, you can't use the TRY..CATCH, and you can't persist a variable across the batches. This is why I used the very kludgy trick of creating a table to indicate an error.
A better way would be to simply have an error table and look for rows in it. Just keep in mind that your ROLLBACK will remove those rows at the end as well.
I would like to get to the bottom of this because it's confusing me. Can anyone explain when I should use the GO statement in my scripts?
As I understand it the GO statement is not part of the T-SQL language, instead it is used to send a batch of statements to SQL server for processing.
When I run the following script in Query Analyser it appears to run fine. Then I close the window and it displays a warning:
"There are uncommitted transactions. Do you wish to commit these transactions before closing the window?"
BEGIN TRANSACTION;
GO
ALTER PROCEDURE [dbo].[pvd_sp_job_xxx]
#jobNum varchar(255)
AS
BEGIN
SET NOCOUNT ON;
UPDATE tbl_ho_job SET delete='Y' WHERE job = #job;
END
COMMIT TRANSACTION;
GO
However if I add a GO at the end of the ALTER statement it is OK (as below). How come?
BEGIN TRANSACTION;
GO
ALTER PROCEDURE [dbo].[pvd_sp_xxx]
#jobNum varchar(255)
AS
BEGIN
SET NOCOUNT ON;
UPDATE tbl_ho_job SET delete='Y' WHERE job = #job;
END
GO
COMMIT TRANSACTION;
GO
I thought about removing all of the GO's but then it complains that the alter procedure statement must be the first statement inside a query batch? Is this just a requirement that I must adhere to?
It seems odd because if I BEGIN TRANSACTION and GO....that statement is sent to the server for processing and I begin a transaction.
Next comes the ALTER procedure, a COMMIT TRANSACTION and a GO (thus sending those statements to the server for processing with a commit to complete the transaction started earlier), how come it complains when I close the window still? Surely I have satisfied that the alter procedure statement is the first in the batch. How come it complains about are uncommitted transactions.
Any help will be most appreciated!
In your first script, COMMIT is part of the stored procedure...
The BEGIN and END in the stored proc do not define the scope (start+finish of the stored proc body): the batch does, which is the next GO (or end of script)
So, changing spacing and adding comments
BEGIN TRANSACTION;
GO
--start of batch. This comment is part of the stored proc too
ALTER PROCEDURE [dbo].[pvd_sp_job_xxx]
#jobNum varchar(255)
AS
BEGIN --not needed
SET NOCOUNT ON;
UPDATE tbl_ho_job SET delete='Y' WHERE job = #job;
END --not needed
--still in the stored proc
COMMIT TRANSACTION;
GO--end of batch and stored procedure
To check, run
SELECT OBJECT_DEFINITION(OBJECT_ID('dbo.pvd_sp_job_xxx'))
Although this is a old post, the question is still in my mind after I compiled one of my procedure successfully without any begin transaction,commit transaction or GO. And the procedure can be called and produce the expected result as well.
I am working with SQL Server 2012. Does it make some change
I know this is for an answer. But words are too small to notice in comment section.
There are a few stored procedures that routinely get called by a few different systems to do maintenance on a few tables in our database. Some are automated, some aren't.
One of the tables has a column where the number is sometimes off, and we don't know for sure when or why this is happening. I want to put a trigger on the table so I can see what is being changed and when, but it'd also be helpful to know which procedure initiated the modification.
Is it possible to get the name of the stored procedure from the trigger? If not, is there any other way to tell what caused something to be modified? (I'm not talking about the user either, the name of the user doesn't help in this case).
you can try: CONTEXT_INFO
here is a CONTEXT_INFO usage example:
in every procedure doing the insert/delete/update that you want to track, add this:
DECLARE #string varchar(128)
,#CONTEXT_INFO varbinary(128)
SET #string=ISNULL(OBJECT_NAME(##PROCID),'none')
SET #CONTEXT_INFO =cast('Procedure='+#string+REPLICATE(' ',128) as varbinary(128))
SET CONTEXT_INFO #CONTEXT_INFO
--do insert/delete/update that will fire the trigger
SET CONTEXT_INFO 0x0 --clears out the CONTEXT_INFO value
here is the portion of the trigger to retrieve the value:
DECLARE #string varchar(128)
,#sCONTEXT_INFO varchar(128)
SELECT #sCONTEXT_INFO=CAST(CONTEXT_INFO() AS VARCHAR) FROM master.dbo.SYSPROCESSES WHERE SPID=##SPID
IF LEFT(#sCONTEXT_INFO,9)='Procedure'
BEGIN
SET #string=RIGHT(RTRIM(#sCONTEXT_INFO),LEN(RTRIM(#sCONTEXT_INFO))-10)
END
ELSE
BEGIN --optional failure code
RAISERROR('string was not specified',16,1)
ROLLBACK TRAN
RETURN
END
..use the #string
Our system is already using the CONTEXT_INFO variable for another purpose so that is not available. I also tried the DBCC INPUTBUFFER solution which almost worked. The draw back to the inputbuffer is that it returns only the outside calling procedure. Ex: procA calls procB which fires a trigger. The trigger runs DBCC INPUTBUFFER which only shows procA. Since my trigger was looking for procB, this approach failed.
What I have done in the meantime is to create a staging table. Now procA calls procB. procB inserts a line in the staging table then fires the trigger. The trigger checks the staging table and finds the procB entry. Upon return procB deletes its entry from the staging table. It's a shell game but it works. I would be interested in any feedback on this.
I've not tried this but ##PROCID looks like it might return what you want.