I have been trying to find out if I can make a column Open on Insert, and closed on Update.
What I mean by that, is I need a column that I can give it a value only on Insert, but if I try to give it a value with Update, the statement would fail.
I am working with SQL 2008...
You can't do this with constraints - you need to use triggers for this.
A trigger is a special kind of stored procedure that automatically executes when an event occurs in the database server. DML triggers execute when a user tries to modify data through a data manipulation language (DML) event. DML events are INSERT, UPDATE, or DELETE statements on a table or view.
Related
Is the BEFORE trigger statement executed before DDL statements or is it inside a DDL statement?
I'm building a small DBMS and currently developing the DDL, and I'm confused about handling the BEFORE statement.
Here's not a defined behaviour for it:
https://web.csulb.edu/colleges/coe/cecs/dbdesign/dbdesign.php?page=sql/ddldml.php
Oracle describes the behaviour but not what can come inside the preceding or following trigger or whether they can be DDL statements or not:
https://www.oracletutorial.com/plsql-tutorial/oracle-trigger/
"BEFORE" is part of the DDL statement that defines the trigger. It describes when the trigger fires in relation to a DML command on a table: i.e. BEFORE or AFTER the change to the data is actually made. This allows you to validate or modify the new data as it is being applied, or to add or modify dependent data like a child table after the parent table update is complete.
While you can technically embed DDL into the body of a trigger using "execute immediate", it is typically considered very bad practice to do so. Is there a specific use case you are considering for including DDL statements in a trigger?
How do I get the performed operation and affected table from a database trigger in oracle?
I want to create a trigger for a schema in Oracle which gets executed on drop or alter or create on database So I need something similar like inserting, updating, deleting but for DDL statements, and somehow I need to know the affected table and schema.
The documentation has a list of the event attribute functions that you can access. It looks like you'd want ora_sysevent for the event along with ora_dict_obj_name and ora_dict_obj_owner to identify the object in question.
I am creating a database level trigger which should only perform a certain action based on which tables were updated.
With a regular trigger I would just use IF UPDATED(column).
Is there some way to determine not just the column that was updated but also the table?
You can't create DDL TRIGGER ON UPDATE
CREATE TRIGGER
DDL triggers, like standard triggers, execute stored procedures in
response to an event. But unlike standard triggers, they do not
execute in response to UPDATE, INSERT, or DELETE statements on a table
or view. Instead, they primarily execute in response to data
definition language (DDL) statements. These include CREATE, ALTER,
DROP, GRANT, DENY, REVOKE, and UPDATE STATISTICS statements. Certain
system stored procedures that perform DDL-like operations can also
fire DDL triggers.
I have created an on update trigger.
If I am updating 5 records in the table in a single statement, how many times will the trigger execute? Does it change if I have multiple statements updating the records in a single transaction?
Does it execute 5 times, or only once after all the transactions are complete?
It all depends on the type of trigger you are using.
a row level trigger will fire for each and every row that is affected by the DML statement (note this is also true for INSERT statements that are based on a SELECT or are using a multi-row syntax to insert more than one row at a time)
a statement level trigger will fire once for the whole statement.
Oracle, PostgreSQL and DB2 support both, row level and statement level triggers. Microsoft SQL Server only supports statement level triggers and MySQL only supports row level triggers.
With SQL 2008:
If you are doing 1 update that updates 5 rows, the trigger should be executed only once.
That's why you have to use the tables "INSERTED" and "DELETED" to be able to detect all the modified rows.
If you are doing 5 updates that update 1 row, the trigger will be executed 5 times.
Considering you are using SQL Server, the trigger will only fire once every Update.
If this is not what you want, you could consider using different update statements to make sure the trigger fires everytime.
You can look at this turorial on SQL triggers. It covers everything.
Note that if you are using Oracle the trigger can be based on rows. Not in SQL Server.
The database I am using already has a 2 triggers on part number table (on insert and on update). Insert trigger updates creation date, and update trigger updates modification date.
I have to add 3 more triggers to log updates to this table (on insert, on update and on delete)
In what order they will be executed? Before existing trigger or after? Can I control that?
sp_settriggerorder will allow you to set first or last trigger.
If you have more than two and the order matters, combine them into one trigger and split the functionality over the stored procedures.