A package specification that does not need a package body is called a bodiless package. Only subprogram and cursor declarations in a package specification require an underlying implementation in the package body. If a package specification declares only those package constructs that do not require implementation details (e.g., types, constants, variables, exceptions, and call specifications), the corresponding package body does not need to be created. However, the body can be created to initialize constructs declared in the package specification.

The UTL_TCP package enables PL/SQL applications to communicate with external TCP/IP-based servers by using TCP/IP. Because many Internet application protocols are based on TCP/IP, the UTL_TCP package is useful to PL/SQL applications that use Internet protocols.

The OPEN_CONNECTION function of the UTL_TCP package opens a TCP/IP connection with the specified remote and local host and port details. The remote host is the host providing the service. The remote port is the port number on which the service is listening for connections. The local host and port numbers represent those of the host providing the service. The OPEN_CONNECTION function returns a connection of PL/SQL record type.

The CLOSE_CONNECTION function of the UTL_TCP package closes an open TCP/IP connection. It takes the connection details of a previously opened connection as parameter. The CLOSE_ALL_CONNECTIONS procedure of the UTL_TCP package closes all open connections.

The READ_BINARY()/TEXT()/LINE() function of the UTL_TCP package receives binary, text, or text line data from a service on an open connection.

The WRITE_BINARY()/TEXT()/LINE() function of the UTL_TCP package transmits binary, text, or text line message to a service on an open connection.

Exceptions are raised when the buffer size for the input is too small, when generic network error occurs, when no more data is available to read from the connection, or when bad arguments are passed in a function call.

In case of local dependencies, the objects are on the same node in the database. The Oracle server automatically manages all local dependencies by using the database’s internal “depends-on” table. When a referenced object is modified, the dependent objects are invalidated. The next time an invalidated object is called, the Oracle server automatically recompiles it. If the automatic recompilation of the object fails, it remains invalid and Oracle server returns a run-time error.

For example, if the structure of a table on which a view is based is modified, the view becomes invalid. When the DESCRIBE command is used to describe the view, an error message is returned stating that the object is invalid to describe. However, if the view is queried, the view is recompiled automatically and the result is displayed if the view gets recompiled successfully.

If the definition of a referenced table is altered, the dependent procedures and functions become invalid. The dependent procedures and functions need implicit or explicit recompilation in order to become valid.

The recompilation of a dependent procedure or function is successful in the following cases:

When a private table is referenced by a dependent procedure, and the private table is dropped, the status of the dependent procedure becomes invalid. When the procedure is recompiled, either explicitly or implicitly, and a public table having the same name and structure exists, the procedure recompiles successfully but becomes dependent on the public table. The recompilation is successful only if the public table contains the columns that the procedure requires; otherwise, the status of the procedure remains invalid.

When a PL/SQL variable is declared to hold column values, it must be ensured that the variable is of the correct datatype and precision. If not, a PL/SQL error occurs during execution. Rather than explicitly specifying the datatype and precision of a variable, the %TYPE attribute can be used to declare a variable according to another previously declared variable or database column.

The %TYPE attribute is generally used when the value stored in the variable will be derived from a table in the database. In order to use the %TYPE attribute in place of the datatype that is required in the variable declaration, the attribute is prefixed with the table name and column name. If referring to a previously declared variable, the attribute is prefixed with the name of the variable.

When a PL/SQL block consisting of such variables is compiled, the PL/SQL determines the datatype and size of the variables in order to ensure that such variables are always compatible with the column that is used to populate it. This is a definite advantage for writing and maintaining code because there is no need to be concerned about column datatype changes made at the database level.

A subprogram is a named PL/SQL block that can accept parameters and be invoked. There are two types of subprograms: procedures and functions. A procedure is generally used to perform an action, and a function is used to compute a value. Subprograms can be stored at the server or application level. By using Oracle Developer components (Forms, Reports, and Graphics), procedures and functions can be declared as part of an application (a form or report) and be called from other procedures, functions, and triggers within the same application whenever necessary.

A function is similar to a procedure, except that a function must return a value to the calling environment, whereas a procedure may or may not return values to its calling environment.

Following is the syntax for creating a procedure:

CREATE [OR REPLACE] PROCEDURE procedure_name
[(parameter [mode] datatype, parameter [mode] datatype, ……)]
IS | AS
PL/SQL block;

where,

The UTL_HTTP Oracle supplied package allows a user to make HTTP requests directly from the database. The UTL_HTTP package makes HTTP callouts from SQL and PL/SQL. The UTL_HTTP package can be used to access data on the Internet or to call Oracle Web Server Cartridges. This package contains two entry point functions: REQUEST and REQUEST_PIECES. Both functions take a string URL (uniform resource locator) as a parameter, contact the site, and return the HTML data obtained from the site. The REQUEST function returns up to the first 2000 bytes of data retrieved from the given URL. The REQUEST_PIECES function returns a PL/SQL table of 2000-byte pieces of the data retrieved from the given URL.

If the HTTP call fails (such as when the URL is not properly specified in the HTTP syntax), the REQUEST_FAILED exception is raised. If an initialization of the HTTP-callout subsystem fails (for a reason such as a lack of available memory), the INIT_FAILED exception is raised. If there is no response from the specified URL, a formatted HTML error message may be returned. If a client user is behind a firewall, he needs to specify proxy as a parameter in addition to the URL.

Reading and writing data into tables by using database triggers are subject to a restriction. The restriction is that the session that issues a triggering statement cannot query (SELECT) or modify (INSERT, UPDATE, DELETE, etc.) a mutating table. A mutating table is a table that is currently being modified by an INSERT, UPDATE, or DELETE statement, or a table that might be updated by the effects of a declarative DELETE CASCADE referential integrity constraint. This restriction prevents a trigger from seeing an inconsistent set of data.

The restriction applies to all row triggers and to those statement triggers that are fired as a result of a DELETE CASCADE event. Any table referencing to a mutating table with a FOREIGN KEY constraint is also a mutating table. However, views being modified through an INSTEAD OF trigger are not considered mutating.

When a trigger encounters a mutating table, the following events occur:

A system event trigger is a database trigger defined on a system event. A system event trigger fires when a system event (such as startup, shutdown, logon, logoff, or error) occurs. Database triggers on system events can be defined at the database or schema level. For example, a trigger on database startup or shutdown can be defined only at the database level. However, a trigger on user logon or logoff can be defined at either the database level or schema level.

Database triggers can be created on the following system events:

Note:

• The trigger on a SERVERERROR event can only be an AFTER trigger.
• The trigger on a LOGON event can only be an AFTER trigger.
• The trigger on a LOGOFF event can only be a BEFORE trigger.
• The trigger on a STARTUP event can only be an AFTER trigger.
• The trigger on a SHUTDOWN event can only be a BEFORE trigger.