To access the database that you want to get data from (query) to create your web page, Oracle Web Publishing Assistant asks you to enter the login information:
Type the User Name that you use to log in to the database you want to query. For example, a sample client user SCOTT is included with the starter database of your Oracle8 product.
Enter the password. The password will appear encrypted for security. For example, the password associated with the user SCOTT is TIGER.
Enter the service name or alias of the database you want to access. To connect to a local database (a database installed on the same machine as the Web Publishing Assistant), leave this field blank.
To use operating system authentication, do not enter the user name and password. The database uses your operating system user profile to log into the database.
See Chapter 3, “Working with Oracle Web Publishing Assistant” in Oracle Web Publishing Assistant for Windows NT for information on configuring Oracle Web Publishing Assistant to support operating system authentication
Click on Start > All Programs > Oracle > Database Administration > Database Configuration Assistant
A trigger defines an action the database should take when some database-related event occurs. The code within a trigger, called the trigger body, is made up of PL/SQL blocks. Triggers are executed by the database when specific types of data manipulation commands are performed on specific tables. Such commands may include inserts, updates, and deletes.
۞ Therefore, you must either own the table, have the ALTER privilege for the table, or have the ALTER ANY TABLE system privilege.
۞ You must have the CREATE TRIGGER system privilege.
۞ To create triggers in another user's account (also called a schema), you must have the CREATE ANY TRIGGER system privilege.
۞ The CREATE TRIGGER system privilege is part of the RESOURCE role provided with Oracle.
۞ To create a trigger on a database-level event, you must have the ADMINISTER DATABASE TRIGGER system privilege.
Row-level triggers execute once for each row in a transaction. For the LEDGER table auditing example described earlier, each row that is changed in the LEDGER table may be processed by the trigger.
Row-level triggers are created using the for each row clause in the create trigger command.
Statement-level triggers execute once for each transaction. For example, if a single transaction inserted 500 rows into the LEDGER table, then a statement-level trigger on that table would only be executed once.
Statement-level triggers are the default type of trigger created via the create trigger command.
Within the trigger, you can reference the old and new values involved in the transaction. "Old" refers to the data as it existed prior to the transaction; updates, and deletes usually reference old values. "New" values are the data values that are the transaction creates (such as the columns in an inserted record).
If you need to set a column value in an inserted row via your trigger, then you need to use a BEFORE INSERT trigger to access the "NEW" values. Using an AFTER INSERT trigger would not allow you to set the insert value, since the row will already have been inserted into the table.
INSTEAD OF Triggers
You can use INSTEAD OF triggers to tell Oracle whet to do instead of performing the actions that invoked the trigger. For example, you could use an INSTEAD OF trigger on a view to redirect inserts into a table or to update multiple tables that are part of a view. You can use INSTEAD OF triggers on either object views or relational views.
For example, if a view involves a join of two tables, your ability to use the update command on records in the view is limited. However, if you use an INSTEAD OF trigger, you can tell Oracle how to inserts, updates, and deletes records in the view's underlying tables when a user attempts to change values via the view. The code in the INSTEAD OF trigger is executed in place of the inserts, updates, or deletes command you enter.
As of Oracle8i, you can create triggers on schema operations. The allowable triggering events include create table, alter table and drop table. You can even create triggers to prevent users from dropping their own tables. For the most part, schema-level triggers provide two capabilities: preventing DDL operations and providing additional security monitoring when DDL operations occur.
You can create triggers to be fired on database events, including errors, logons, logoffs, shutdowns and startup. You can use this type of trigger to automate database maintenance or auditing actions.