What are two virtual tables available during database
trigger execution ?
Answers were Sorted based on User's Feedback
Answer / tulsi
The table columns are referred as OLD.column_name and
NEW.column_name.
For triggers related to INSERT only NEW.column_name values
only available.
For triggers related to UPDATE only OLD.column_name
NEW.column_name values only available.
For triggers related to DELETE only OLD.column_name values
only available
Is This Answer Correct ? | 12 Yes | 3 No |
If a View on a single base table is manipulated will the changes be reflected on the base table?
what is the difference between where clause and having clause? : Sql dba
How to select all records from the table?
Can function return multiple values in sql?
what is bulk bind
create a store procedure and created synonms for that store procedure after modify that store procedure will effect on synonms? If we delete the store procedure what happened to that synonms?
can we delete the trigger in a view? if yes why if not why?
What happens when a trigger is associated to a view?
How can we overcome recursive triggers in SQL?
How do you update a value in sql?
what is datawarehouse? : Sql dba
create SQL (both DML/DDL) statements appropriate for the creation of relational structures & constraints and other objects for a given case study, the population of these tables and the manipulation (querying/updating) of the stored data. 2. Create, develop and use the PL / SQL Program Units Procedures, Functions as a progression towards Object Oriented Relational Database Programming. 3. Package a collection of logically related Procedures and Functions together to further move towards development of Objects which reflect the principle of Data Abstraction whereby only an Object specified in the Interface is accessible to the end user. 4. Select, create, and use appropriate Database Triggers to impose agreed specific constraints on a Database Table. 5. Provide a full and detailed evaluation which includes a comprehensive test execution plan and its implementation for each of the above. Consider the following case study: Perilous Printing is a medium size printing company that does work for book publishers throughout UK. The company currently has 10 offices, most of which operate autonomously, apart from salaries, which are paid by the head office. Currently the sharing and communication of data, is carried out using multi- user networked access to a centralised RDBMS. Perilous Printing jobs consist of printing books or part of books. A printing job requires the use of materials, such as paper and ink, which are assigned to a job via purchase orders. Each printing job may have several purchase orders assigned to it. Likewise, each purchase order may contain several purchase order items. The following tables form part of the transactional RDB that the company uses: office (office_no, o_addr, o_telno, o_faxno, mgr_nin) staff (staff_no, nin, fname, lname, s_addr, s_telno, gender, dob, position, taxcode, salary, office_no) publisher (pub_no, p_name, p_city, p_telno, p_faxno, credit_code, office_no) book_job (job_no, pub_no, job_date, job_desc, job_type, job_status, supervisor_nin) purchase_order (job_no, po_no, po_date) po_item (job_no, po_no, it_no, qty) item (it_no, it_desc, amt_in_stock, price) office contains details of each office and the office number (office_no) is the key. Each office has a Manager represented by the manager’s national insurance number (mgr_nin). staff contains details of staff; the staff_no is the key. The office that the member of staff works from is given by office_no. publisher contains details of publisher and the publisher number (pub_no) is the key. Publishers are registered with the nearest office in their country, given by office_no, and they are given a credit code that can have the values “AA”, “AB”, “BB”, “BC”, “CC”, “CD” and “DD”. If a publisher is to be deleted then not only the publisher’s entry from the publisher table will have to be removed but all the data associated with the particular supplier has to be deleted too book_job contains details of publishing jobs and the job number (job_no) is the key. The publisher is given by the publisher number (pub_no) and the supervisor for the job by supervisor_nin. The job type can be either null or urgent; whereas the job_status can be “ongoing” or “completed” purchase_order contains details of the purchase orders for each job and the combination of job number and a purchase order number (job_no, po_no) form the key. Each printing job may have several purchase orders assigned to it. item contains details of all materials that can be used in printing jobs and the item number (it_no) is the key. po_item contains details of the items on the purchase order and (job_no, po_no, it_no) forms the key. In the above given database schema, descriptions are strings of characters (at most 30 characters long), any dates (except the job_ date) stored cannot be after the current system date, and quantities and prices are assumed to be non-negative numbers.