Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 6 years ago.
Improve this question
I'm trying to create a trigger in the 'CabecDoc' table so that it adds a field to the 'Test' table (the field being 'Artigo').
I thought this trigger would do the trick, but it doesn't! It does nothing! It does not create any record on my 'Test' table. Can you help?
USE [PRICLONEPRJ]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TRIGGER [dbo].[CriarContrato]
ON [dbo].[CabecDoc]
AFTER INSERT
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
set ansi_warnings on
set ansi_nulls on
SET NOCOUNT ON;
INSERT INTO Test (Artigo)
select LinhasDoc.Artigo
from inserted INNER JOIN
LinhasDoc ON inserted.Id = LinhasDoc.IdCabecDoc
END
Is there any way to debug this code within SMSS?
Try insert this row
EXEC xp_logevent 60000, 'CriarContrato works', informational;
at the begining of trigger body. And then you should see this log in SSMS - Object Explorer - Management - Sql Server Logs - Current
If it works, you can add this after INSERT:
declare #log varchar(2048) = CONCAT('CriarContrato inserted ', ##ROWCOUNT, ' rows');
EXEC xp_logevent 60000, #log, informational;
or something else.
Related
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.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 6 years ago.
Improve this question
I've to help migrating a SQL Server 2008 database to a PostgreSQL 9.4.10 one. The original querys have SET NOCOUNT ON and SET NOCOUNT OFF several times, and I can't change this fact so ignoring the number of rows affected isn't a solution. That's why I need to find an equivalent to this statement, but all I can find are really old posts where they say I should ignore the result. Any ideas? Thanks.
EDIT: these SET NOCOUNTare inside a stored procedure that goes like this:
CREATE PROCEDURE [procedureName]
Declares
--Variables
WITH ENCRYPTION
AS
SET NOCOUNT ON
--Procedure's code
SET NOCOUNT OFF
GO
As I've said this code isn't mine, so I can't post any of it more than the source of my doubt.
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'm trying to modify the results of another applications stored procedure, so I have no access to change the code that is reading the result set. (c#) but I can change the SP, Every time I modify the SP I get the error 'Fetch type out of range' . After searching stack overflow it appears that the software is calling this SP is using cursors, so my question is -
Can I exclude some of the results below from being read by the client code and giving the error?
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[Find_Door] ##somevar varchar(50)='' AS
--Normal part, return this
SELECT a.[Name] FROM People AS a
--Additional code, I don't want the cursor to be able to read.
DECLARE ...
INSERT INTO Tables (col1,col2) VALUES ('val',getdate())
---
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
If a Table A is updated a trigger gets fired. That trigger calls another SP to do some processing.
Is there any chance that if SP fails the update that happened on Table A will be reverted?
I have a code just after the update "If Sqlca.SqlCode" and this always has 0 coming for the update.
Please Help!!
Yes, if the trigger encounters an error (internally or through calling some external procedure) and rolls back the transaction, it will roll back the whole transaction, including whatever UPDATE caused the trigger to fire in the first place. There are multiple ways to get around this, if it is not the behavior you want:
use TRY / CATCH to absorb any errors form the external procedure, or move the procedure logic into the trigger, or add proper error handling to the stored procedure so that, if you don't care that an error happened there, it doesn't bubble up and roll back everything.
use an INSTEAD OF trigger - combined with TRY / CATCH (or possibly committing your own UPDATE first), you should be able to update the table without caring whether the external stored procedure fails.
Example of the INSTEAD OF trigger:
USE tempdb;
GO
CREATE TABLE dbo.flooblat(id INT PRIMARY KEY, name VARCHAR(32));
INSERT dbo.flooblat(id,name) VALUES(1, 'Bob');
GO
CREATE PROCEDURE dbo.oh_my
AS
SELECT 1/0;
GO
CREATE TRIGGER dbo.trFlooblat
ON dbo.flooblat
INSTEAD OF UPDATE
AS
BEGIN
SET NOCOUNT ON;
UPDATE f SET f.name = i.name
FROM dbo.flooblat AS f
INNER JOIN inserted AS i
ON f.id = i.id;
COMMIT TRANSACTION;
EXEC dbo.oh_my;
END
GO
UPDATE dbo.flooblat SET name = 'Frank';
GO
SELECT id, name FROM dbo.flooblat;
GO
Results:
Msg 8134, Level 16, State 1, Procedure oh_my
Divide by zero error encountered.
The statement has been terminated.
However, the SELECT reveals that, even though an error occurred in the trigger, it happened after the UPDATE was committed - so unlike an exception that occurs in an AFTER trigger (without proper error handling), we were able to prevent the error from rolling back all of the work we've done.
id name
---- -----
1 Frank
Triggers can do things AFTER the DML is executed, INSTEAD OF executing the DML, etc. So yes, there is a chance that the update (dml) wont happen if the SP fails -- just depends on how you write it / what features you use.
Read up on triggers a bit here: http://technet.microsoft.com/en-us/library/ms189799%28v=sql.105%29.aspx
If you want a more specific answer for trigger in quesiton, then you'll need to post the code.