Is there a way to update/alter all triggers using Looping T-SQL or a C# Code ?. I need it too update all the triggers in my database because the RAISERROR command has changed in sql server 2012.
You can script out all the triggers into a text file. See:
How to Generate Scripts For All Triggers in Database Using Microsoft SQL Server Management Studio
Then, you can use a text editor to replace the code you need to replace. Then, you can drop your triggers and recreate them. I don't know if your referring to a production database, or one that you are doing development on. I am assuming from your question that you are prepared to make these major changes to your database. Make sure you back up your database first, in any event.
You can get all trigger using
SELECT [name] FROM [sys].[triggers]
and loop through each trigger and execute
EXEC sp_helptext 'TriggerName'
so you will have the create statement with it...
Related
I'm trying to write a T-SQL script to create a database and the corresponding tables. I'm having a problem where the USE statement complains that the database that I just "created" doesn't exist. If I run the script within SQL Server Management Studio so that I can make use of the GO statement, I don't get this issue.
Is there a T-SQL equivalent of GO that I can use to make sure the CREATE DATABASE gets executed before the USE?
I've tried BEGIN/COMMIT TRANSACTION and BEGIN/END but they didn't help.
Is there a T-SQL equivalent of GO that I can use to make sure the CREATE DATABASE gets executed before the USE?
Yes. Dynamic SQL. Each dynamic SQL invocation is a parsed, compiled, and executed as a separate batch.
EG:
exec ('
create database foo
')
exec ('
use foo
create table bar(id int)
')
Note that when used in dynamic SQL use database only change the database context for the dynamic batch. When control returns to the calling batch, the database context is restored.
In C# you should use separate calls to SqlComand for each batch.
High level steps.
Open connection to master.
Create new database (just create database statement).
Instead of USE call SqlConnection.ChangeDatabase(String) Method
Execute remaining batches
The database I'm working on has a trigger which calls a stored procedure which takes 42 seconds to run if I do an UPDATE using T-SQL. If I edit the row in SQL Server Management Studio, the row updates instantly. Triggers are executed in the edit window as well as on T-SQL UPDATES, aren't they?
The SQL code in the stored procedure comes back instantly if I run it directly or call it using EXEC, the only circumstances when it runs slowly are when the trigger is called by an UPDATE statement.
It depends how the trigger was set up, Triggers will only run on Update, Delete and Insert statements (Depending which of the three are chosen) On the table it is set against.
Could you give the code used to create the trigger?
These triggers run after an insert, update or delete on a table
click here for details about different type of triggers and demo for triggers
I am using Microsoft SQL Server 2008 R2 (SP2). I am not using SQL Server Management Studio. I am using a simple webpage with a textarea for a query window that I built myself in PHP, so all I am doing are SQL commands -- no GUI stuff. Never had problems with it before, and I don't think the problems I'm having now are because of my PHP. Anyway, I would most appreciate answers in SQL code rather than answers that recommend I right-click the table name in Management Studio, if you get my drift.
Leading up to the problem...
I used to have three triggers on table dbo.MyOldTableName:
trgOldUpdate1, trgOldUpdate2, and trgOldInsert
I renamed the table using the following code:
EXEC sp_rename 'dbo.MyOldTableName', 'MyNewTableName';
I then dropped those three old triggers and created the following three new triggers (which do the same thing but point to the new table and have new names):
trgNewUpdate1, trgNewUpdate2, and trgNewInsert
I ran this SQL and saw only the new triggers:
SELECT
referencing_schema_name,
referencing_entity_name,
referencing_id,
referencing_class_desc,
is_caller_dependent
FROM
sys.dm_sql_referencing_entities ('dbo.MyOldTableName', 'OBJECT');
I ran this SQL and the old triggers are not there:
SELECT * FROM sys.triggers;
Now all of that above information is simply background. Here is the actual problem. I ran a simple update command (like this SQL):
UPDATE [dbo].[MyNewTableName] SET ColumnName = ColumnName;
...and got these error messages:
Cannot drop the trigger 'dbo.trgOldUpdate2', because it does not exist or you do not have permission.
Cannot drop the trigger 'dbo.trgOldUpdate1', because it does not exist or you do not have permission.
Cannot drop the trigger 'dbo.trgOldUpdate1', because it does not exist or you do not have permission.
Cannot drop the trigger 'dbo.trgOldUpdate2', because it does not exist or you do not have permission.
First, why is SQL Server trying to drop triggers on a simple update command (And before you ask, no, the trigger code itself never drops anything at all)?
Second, why is SQL Server looking for triggers that don't exist?
Third and most important, how do I stop this from happening?
Many thanks in advance for your clear, concise, and self-contained answers! (Hey, a guy can dream, can't he?)
My guess is that there was an error in the trigger DROP/CREATE script such that the DROP statements of the old triggers were inadvertently included in in one of the update triggers. Check the new triggers to see if that is the case:
EXEC sp_helptext N'trgNewUpdate1';
EXEC sp_helptext N'trgNewUpdate2';
Can you advice me how I can retrieve caller ID or Name which executed a trigger?
For example I want to know which SP executes a trigger or maybe trigger called by updates from management studio?
I know that ##PROCID returns ID of trigger and can't be used.
Also I know solution when in SP we write CONTEXT_INFO and read it from trigger.
But in this case we should SET CONTEXT_INFO in all SPs that modifies some table.
Is there exists some simplest way like ##PROCID ?
If it's SQL Server 2005 or 2008, and a DDL trigger, you can use eventdata().
Here's a link to the msdn page.
Basically it returns an XML dataset that you can parse to get things like who called it (data(/EVENT_INSTANCE/LoginName)[1]), what the command was, etc.
I have a script in T-SQL that goes like this:
create table TableName (...)
SET IDENTITY INSERT TableName ON
And on second line I get error:
Cannot find the object "TableName" because it does not exist or you do not have permissions.
I execute it from Management Studio 2005. When I put "GO" between these two lines, it's working. But what I would like to acomplish is not to use "GO" because I would like to place this code in my application when it will be finished.
So my question is how to make this work without using "GO" so that I can run it programmatically from my C# application.
Without using GO, programmatically, you would need to make 2 separate database calls.
Run the two scripts one after the other - using two calls from your application.
You should only run the second once the first has successfully run anyway, so you could run the first script and on success run the second script. The table has to have been created before you can use it, which is why you need the GO in management studio.
From the BOL: "SQL Server utilities interpret GO as a signal that they should send the current batch of Transact-SQL statements to SQL Server". Therefore, as Jose Basilio already pointed out, you have to make separate database calls.
If this can help, I was faced with the same problem and I had to write a little (very basic) parser to split every single script in a bunch of mini-script which are sent - one at a time - to the database.
something even better than tpdi's temp table is a variable table. they run lightning fast and are dropped automatically once out of scope.
this is how you make one
declare #TableName table (ColumnName int, ColumnName2 nvarchar(50))
then to insert you just do this
insert into #TableName (ColumnName, ColumnName2)
select 1, 'A'
Consider writing a stored proc that creates a temporary table and does whatever it needs to with that. If you create a real table, your app won't be able to run the script more than once, unless it also drops the table -- in which case, you have exactly the functionality of a temp table.