o8i plsql app dev twp

8/14/2019 o8i plsql app dev twp

1/25

Oracle8 iPL/SQL

Ease-of-Use

and Application Development

An Oracle Technical White Paper

M arch 199 9


2/25

Oracle8i PL/ SQL Ease-of-Use and Application Development

March 1999

2

OVERVIEW

The PL/SQL language, Oracles procedural extension to industry-standard SQL, is an easy-to-use,

full-fledged programming language that integrates many features, such as data encapsulation,

information hiding, overloading, and exception handling. The PL/SQL platform is a compelling

platform for application development for the following reasons:

= PL/SQL provides seamless and tight integration with SQL, with natural, efficient, and safeextensions to the SQL language.

= An inherent strength that PL/SQL has is the power to evolve the language, which helps to naturallyand easily solve customer problems.

= Embedded in the Oracle Server, the PL/SQL platform provides excellent support for PL/SQL storedprocedures as well as the ability to build scalable, portable, and highly robust Enterprise

applications on the server using these.

= Embedded in the Oracle Developer and Oracle Developer Server products, the PL/SQL platformprovides a consistent application development environment, including the ability to drag and drop

procedures across tiers. PL/SQL procedures may be compiled and executed in the client or

middle tier.

As more and more applications deployed at the Enterprise level use PL/SQL heavily, there is an

increasing need to make the PL/SQL application development platform easier to use.

Oracle8i PL/SQL Release 8.1 includes a number of improvements that ease the development of

applications based on Oracle. Some of the improvements are transparent, allowing application

developers to benefit from these almost immediately, while some of the improvements involve new

language features that make programming applications much simpler. Oracle8i PL/SQL Release 8.1

also provides seamless interoperability with Java

, executing in the server, and with C procedures,

executing in a separate process.

This paper focuses on the ease-of-use improvements and application development enhancements in

Oracle8i PL/SQL Release 8.1.

For a general overview of all Oracle8i PL/SQL Release 8.1 features, and for a discussion on future

directions, please refer to [1], an Oracle technical white paper on Oracle8 i PL/SQL - New Features

and Future Directions.


3/25


March 1999

3

Oracle8i PL/SQL Release 8.1 also includes a number of performance improvements. For a detailed

discussion on the performance of PL/SQL programs, please refer to [3], an Oracle technical white

paper on Techniques for Tuning PL/SQL Applications.

The following table summarizes the new Oracle8i PL/SQL Release 8.1 features that make PL/SQL

much easier to use:

Areas Features

Transparent

Ease-of-use

Enhancements

= Ability to compile much larger package bodies, by relaxing an internal limitthat gave rise to the compilation time error PLS-123: program too large.

= Improved diagnostics for ORA-6502: numeric or value error, with the use ofadditional subtext in many cases.

= Enhanced ability to interoperate with older releases.PL/SQL

Language

Enhancements

= Improved callability from SQL, relating to purity and pragmaRESTRICT_REFERENCES. Transparent improvements (relaxed compilation

time restrictions) and simpler syntax.

= Improved ability to write dynamic SQL code much more easily, using the newnative dynamic SQL feature, rather than the DBMS_SQL package interface.

= Improved ability to log diagnostic messages at runtime much more easily, usingthe new autonomous transactions feature.

= Ability to create procedures that execute with the callers privileges (invoker-rights procedures).

= Ability to query local PL/SQL collection variables.= Enhanced extensibility of the database, using schema-level

user-defined operators.

= Ability to write static methods in object types.


4/25


March 1999

4

Interoperability

with C, Java

= Seamless interoperability with Java.= Ability to pass object types, collection types, and REF types to external

C programs.

= Additional mappings for basic types, when calling out to externalC procedures.

= Ability to use Pro*C to write external procedures SQL callbacks muchmore easily.

= Ability to specify call-specifications that may be placed in the package andtype specifications, instead of just the body.

Tools for

Application

Development

= Support for tracing, profiling and performing code-coverage of PL/SQLprograms through the use of new Probe API extensions. These extensible,

open family of APIs, which included support for debugging in previous

releases, may be used by 3rd party vendors to build development environments

to debug and monitor PL/SQL programs

TRANSPARENT EASE-OF-USE IMPROVEMENTS

PACKAGE BOD Y SIZE LIMIT INCREASED

Prior to Oracle8i PL/SQL Release 8.1, the compilation of very large package and type bodies and

anonymous blocks resulted in the compilation time error PLS-123: Program too large, due to an

internal compiler limit. To work around this limitation, application developers split their packages

and type bodies into smaller units. In Oracle8i PL/SQL Release 8.1, this is no longer necessary,

because the internal compiler limit has now been substantially increased, allowing much larger

package and type bodies to be compiled. While it is not easy to correlate this internal limit with

number of lines of PL/SQL source code, it is estimated that an application developer would now be

able to write up to 6 millions lines of code in a single package or type body, provided other limits

arent reached. Note that the limit for other types of program units (schema-level functions and

procedures, package and type specs) has not been increased.


5/25


March 1999

5

ORA-6502: NUM ERIC OR VALUE ERROR M ESSAGE IMPROVED

In Oracle8i PL/SQL Release 8.1, the runtime ORA-6502 error message that customers frequently

encounter is now improved to display subtext that state the reason (in most cases) why the error

occurred. This should help customers find problems in their code much more easily. For example:

declare

x varchar2(1);

begin

x := '12';

end;

Instead of seeing the more cryptic ORA-6502: numeric or value error, the application developer

will now see the following, much more informative error: ORA-6502: PL/SQL: numeric or value

error: character string buffer too small. In the case of:

declare

x number;

begin

x := 'abc';

end;

The application developer will see the following, much more friendly error: ORA-6502: PL/SQL:

numeric or value error: character to number conversion error.

Subtexts for the ORA-6502 exceptions have been added for the most common ones that the PL/SQL

runtime engine throws, such as conversion errors. In future releases, Oracle expects to improve more

of the ORA-6502 messages, by adding more subtexts.


6/25


March 1999

6

Note that the sub message text will be displayed for all unhandled ORA-6502 exceptions on the

client and server, and for handled exceptions on the server, via sqlerrm. This, however, will not occur

for handled exceptions on the client.

Although this new functionality doesn't implement the full blown parameterized exceptions

functionality that would be nice to have, it is an initial step in that direction, and should aid PL/SQL

developers who find the generic 6502 exception message hard to use.

IMPROVED INTEROPERABILITY

Although PL/SQL procedures and functions stored in an Oracle7

database or an Oracle Developer

product containing PL/SQL Release 2.3 can make calls to all remote packaged procedures stored in a

remote database, they can call only those schema-level procedures that do not contain the use of any

new Oracle8

features. In Oracle8i, this limitation no longer applies. This means that a procedure

stored in an Oracle7 or Oracle8 database, or an Oracle Developer product that contains PL/SQL

Release 2.3 or Release 8.0 may now call all remote procedures. This is true, regardless of whether the

remote procedures are packaged procedures or schema-level procedures and whether these remote

procedures contain the use of any new Oracle8 i PL/SQL Release 8.1 features.


7/25


March 1999

7

PL/SQL LAN GUA GE ENHA NCEM ENTS

IMPROVED CALLABILITY FROM SQL - TRANSPARENT AND LANGUAGE SYNTAX

IMPROVEMENTS

The purity of a stored procedure refers to the side-effects of that procedure on database tables or

packaged variables. Various side-effects are disallowed when a function is called from a SQL query or

DML statement. This is discussed in [6] Oracle8 Application Developers Guide, Release 8.0.

The mechanism in Oracle7 and Oracle8 leveraged the PL/SQL compiler, to enforce restrictions

during the compilation of a stored procedure, or the compilation of a SQL statement. In Oracle8i

PL/SQL Release 8.1, the compilation time restrictions have been relaxed, and instead a smaller set of

restrictions are enforced during execution. This change was made with two goals in mind:

= To provide uniform support for stored procedures written in PL/SQL, Java, and C.= To allow developers to worry less about PRAGMA RESTRICT_REFERENCES declarations.

In addition, many restrictions have been safely removed in order to allow programmers the most

flexibility possible.

In short, PRAGMA RESTRICT_REFERENCES is no longer required to allow a function to be

called from SQL. Instead, the Oracle8i server simply verifies during execution that:

= A function called from a query (SELECT statement) or a parallelized DML statement does notexecute any DML or in any other way modify the database.

= A function called from a query or DML statement does not end the current transaction, create orrollback to a savepoint, or ALTER the system or session.

= A function called from a DML statement does not read or modify the particular table that that DMLstatement modifies.

Pragma RESTRICT_REFERENCES may still be used, if desired, to request that the PL/SQL

compiler identify statements or calls that have side-effects beyond those expected. A new keyword,TRUST, has been added to the pragma RESTRICT_REFERENCES syntax. This allows the easy

calling of a subprogram that does not have the pragma from one that does by creating a wrapper

subprogram that uses the pragma with this new keyword that then calls the subprogram that does

not have the pragma.


8/25


March 1999

8

In addition, two new keywords, DETERMINISTIC and PARALLEL_ENABLE, have been added to

the syntax for declaring a function. These are optimization hints to inform the query optimizer and

other aspects of Oracle8i about properties of the function.

= The DETERMINISTIC keyword is a hint to indicate that the function returns results in adeterministic manner and, therefore, need not be called redundantly. This functionality is new in

Oracle8i PL/SQL Release 8.1, and is used in the context of some new features, like

functional indexes.

= The PARALLEL_ENABLE keyword is a hint to indicate that a function may be called from withina parallel_query or parallel DML statement. In releases prior to Oracle8i PL/SQL Release 8.1, this

property was indicated in a somewhat non-obvious manner, via the WNPS and RNPS options of

the pragma RESTRICT_REFERENCES syntax.

Pragma RESTRICT_REFERENCES may still be used to request that the PL/SQL compiler identify

statements or calls that have side-effects beyond those expected.


9/25


March 1999

9

NATIVE DYNAMIC SQL

Dynamic SQL refers to the ability to dynamically build and submit SQL statements for execution,

while in the midst of an execution of a PL/SQL procedure. Since the content of these statements can,

and probably will change with every execution, they are referred to as dynamic SQL statements.

Dynamic SQL statements may include data manipulation language (DML) statements (i.e., INSERT,

UPDATE, DELETE, SELECT), PL/SQL anonymous blocks, data definition language (DDL)

statements, transaction control statements, session control statements (with some restrictions), etc.

Dynamic SQL is very useful for applications that allow users to choose query search criteria or

optimizer hints at run time. Such uses are often required in database query tools, in interactive

database applications that present the user with information specific to their needs, and in

application code that is reusable and, therefore, independent of the actual SQL statement

being executed.

Prior to Oracle8i PL/SQL Release 8.1, the only way to program dynamic SQL statements inside

PL/SQL procedures involved the use of the programmatic interface provided through the

DBMS_SQL package. While this interface addresses the basic need for the dynamic SQL

functionality, it tends to be somewhat cumbersome to use, and generally results in code clutter and

code explosion.

Oracle8i PL/SQL Release 8.1 now provides the dynamic SQL capability directly through the PL/SQLlanguage, with new syntax and extensions of existing syntax. The new native dynamic SQL

functionality provides the following benefits over DBMS_SQL:

= The new syntax is highly intuitive, much easier to use, and highly conducive to quick coding.= Programs written using the new functionality are a lot more compact, readable, and maintainable.= The performance of programs that use the new native dynamic SQL functionality is substantially

better than those that use the DBMS_SQL interface.

The PL/SQL language has been extended to support dynamic SQL in the following ways:

= A new EXECUTE IMMEDIATE statement has been added, to allow the application developer toprepare, execute, and deallocate a dynamic SQL statement. For example:

EXECUTE IMMEDIATE 'insert into ' || table_name || ' values

(:1, :2) ' USING val1, val2;

Note that the bind arguments to the dynamic SQL statement are specified in the USING clause.


10/25


March 1999

10

= The syntax of the OPEN cursor statement has been extended to support the opening of ref cursorvariables on a dynamic SQL query that is specified as a string. For example:

OPEN ref_cursor_var

FOR 'select * from ' || table_name || ' where sal > :s '

USING salary;

= The existing FETCH and CLOSE statements have been extended to support dynamic cursorswithout any syntax changes.

The example below demonstrates the benefits of native dynamic SQL over the DBMS_SQL package:

DML Example using the

DBMS_SQL package

Equivalent D M L Example w ith

Native Dynamic SQL

PROCEDURE insert_into_table (

table_name VARCHAR2,

deptnumber NUMBER,

deptname VARCHAR2,

location VARCHAR2 )

IS

cur_hdl INTEGER;

s tm t_s tr VA RC HAR 2(2 00 );

rows_processed BINARY_INTEGER;

BEGIN

stmt_str :=

'insert into ' || table_name ||

' values (:deptno, :dname, :loc)';

-- open cursor

cur_hdl := dbms_sql.open_cursor;

PROCEDURE insert_into_table (

table_name VARCHAR2,

deptnumber NUMBER,

deptname VARCHAR2,

location VARCHAR2 )

IS

stmt_str VARCHAR2(200);

BEGIN

stmt_str :=

'insert into ' || table_name || '

values (:deptno, :dname, :loc)';

-- bundled execution using native

-- dynamic SQL

EXECUTE IMMEDIATE stmt_str

USING deptnumber, deptname, location;


11/25


March 1999

11

-- parse cursor

dbms_sql.parse(cur_hdl, stmt_str,

dbms_sql.native);

-- supply binds

dbms_sql.bind_variable(cur_hdl,

':deptno', deptnumber);


':dname', deptname);


':loc', location);

-- execute cursor

rows_processed :=

dbms_sql.execute(cur_hdl);

-- close cursor

dbms_sql.close_cursor(cur_hdl);

END insert_into_table;

END insert_into_table;

The new dynamic SQL capability also provides significant performance improvements over

DBMS_SQL. Internal benchmarks using Oracle8i PL/SQL Release 8.1.3 demonstrated a 1.5 to 3.2

times improvement in performance. For more information about the performance benefits of this


12/25


March 1999

12

feature, please refer to [3], an Oracle technical white paper on Techniques for Tuning

PL/SQL Applications.

For more details on the new native dynamic SQL capability, please refer to [2], an Oracle technical

white paper on Native Dynamic SQL in PL/SQL.

AUTONOMOUS TRANSACTIONS FOR BUILDING REUSA BLE COMPON ENTS AN DIM PROVED LOGGING

In many applications, it is often required to perform various logging operations (e.g., error logging,

audit logging) without being affected by the current transaction context. In releases prior to

Oracle8i PL/SQL Release 8.1, this functionality could be implemented only using DBMS_PIPE,

which required the calling procedure to communicate with a daemon process that performed the

logging in a separate session and transaction. While DBMS_PIPE is very powerful and flexible,

programming with DBMS_PIPE is often tedious and results in code that is cumbersome, hard to

read and maintain, and inefficient.

An application developer building an application with interacting components that perform

transactional operations is faced with the problem that these components could step over each others

transaction context. Prior to Oracle8i PL/SQL Release 8.1, there was no automatic way to isolate the

transactional activities of various components. It often required sett ing up contrived design and

coding practices that needed to be strictly adhered to. However, this often let to clumsy and

contrived designs that were error-prone. Consider a situation where an application developer wants

to build a component where a commit in that component does not also commit the transactional

changes of the calling component. Either the calling component would need to ensure that it is not

in the middle of a transaction when performing the call, or, if this is not possible, the components

would need to be redesigned, so that the called components would never perform commits. Instead

commits would need to be done as separate operations. Both choices result in contrived designs, and

leave room for error-prone coding.

Oracle8i introduces autonomous transactions, to much more effectively solve such problems. An

autonomous transaction is an independent transaction started within the context of another

transaction, the parent transaction. It shares no locks, resources, or commit-dependencies with the

parent transaction. Autonomous transactions provide all the functionality of regular transactions.

They also allow parallel queries, distributed processing, and all transaction control statements.


13/25


March 1999

13

Oracle8i PL/SQL Release 8.1 exposes this feature through pragma AUTONOMOUS_TRANSACTION,

a new compiler directive. Using this pragma, PL/SQL schema level subprograms, local subprograms,

package or type methods and schema-level anonymous blocks may be declared as autonomous

transaction blocks. Upon entering an autonomous transaction block, the callers transaction context

is automatically suspended. Any subsequent SQL operations that need to be done within a

transaction will trigger the creation of a new autonomous transaction context. SQL operations may

then be performed, committed, or rolled back within the autonomous transaction context, with no

effect on the parent transaction. Although an autonomous transaction block may hold only one open

autonomous transaction context at any point during execution, the autonomous transaction block

may sequentially start and end several autonomous transactions. It may also call other autonomous

transaction blocks. Before exiting an autonomous transaction block, all autonomous transactions

must be explicitly committed or rolled back, or else an exception is raised upon exit. Upon exit from

the block, the parent transactions context is automatically restored, with no effect on the completed

autonomous transaction.

In performing logging operations, autonomous transactions provide a significant advantage over

DBMS_PIPE, as the result ing code is greatly simplified and much more efficient. A procedure that

starts an autonomous transaction may be called to log events that will stay committed even if the

parent transaction rolls back.

More importantly, autonomous transaction blocks help the application developer build modular

reusable software components that perform specialized transactional operations. This may be done

by writing stored procedures to independently start and finish autonomous transactions independent.

A calling application need not know about a procedures autonomous transactional operations, and

the procedure need not know about the calling applications transaction context. This makes

autonomous transactions much less error-prone and much easier to use than regular transactions.

The following example illustrates a simple use of this feature:

CREATE OR REPLACE PROCEDURE debug_log1 (message VARCHAR2) AS

BEGIN

INSERT INTO debug_table VALUES (message);

END debug_insert1;

/


14/25


March 1999

14

CREATE OR REPLACE PROCEDURE debug_log2 (message VARCHAR2) AS

pragma AUTONOMOUS_TRANSACTION;

BEGIN

INSERT INTO debug_table VALUES (message);

commit;

END debug_insert1;

/

BEGIN

UPDATE emp SET sal = 1000000 WHERE ENAME = KING;

debug_log1(TRIED TO UPDATE SALARY OF KING TO 1000000 - log 1);

UPDATE emp SET sal = 1000000 WHERE ENAME = SMITH;

debug_log2(TRIED TO UPDATE SALARY OF SMITH TO 1000000 - log 2);

ROLLBACK;

/*

** At this point we lose all record of the fact that we attempted

** to change KINGs salary to 1000000 since debug_log1 does not

** use autonomous transactions.

** However, we do retain a record of the fact that we attempted

** to change SMITHs salary to 1000000 since debug_log2 does

** use autonomous transactions.

*/

END;

/


15/25


March 1999

15

INVOKER-RIGHTS PROCEDURES: INHERITING CALLER CONTEXT

Prior to Oracle8i, the only privilege and name-resolution context model that was supported was the

definer-rights model. In this model, a PL/SQL stored procedure may execute only with the privileges

of the user that created the procedure, and in the name-resolution context of that users schema.

Before allowing the procedure to execute any operation on a database object, Oracle verifies that the

procedures owner has the required privileges. In addit ion, stored procedures are bound to their

owners schema; i.e., unqualified object names are resolved in the procedure owners schema.

Definer-rights procedures help the application developer encapsulate access to database objects that

may not be public.

Oracle8i introduces a new complementary privilege and context model with invoker-rights procedures.

An invoker-rights procedure inherits the privileges and name-resolution context of the user from the

calling procedure. Although Oracle supplies several DBMS_* packages that behave like invoker-

rights packages (for instance, DBMS_SQL accepts a SQL string from a user and parses and executes it

on behalf of the user, despite being owned by SYS), the mechanism was internal and restricted to a

few packages in prior releases. Oracle8i formalizes and exposes these mechanisms to all users.

Invoker-rights stored procedures provide the ability to write and install a single copy of code that

multiple users can invoke to manipulate objects in different schemas, depending upon the calling

context. This can be extremely useful if an application must execute SQL on behalf of the user

calling it.

An invoker-right s procedure may be specified, using the new AUTHID clause. For example:

create or replace package sales AUTHID CURRENT_USER as ...

This clause may be used on a package or type specification, or on a schema-level procedure or

function. This clause may not be used on a package or type body, or on a nested

function or procedure.

The next few sub-sections walk the reader through a simple example that compares the two models.

Consider a company database that stores sales information for a number of regional company sales

offices. Sales data is stored in table SALES_TAB in each regions schema, and accessed through

sales, an application package that encapsulates access to the data in SALES_TAB.


16/25


March 1999

16

Definers Rights -> Code Duplication

Figure 1. Sales database for a company with multiple regional sales offices.Broken lines indicate package invocation. Solid lines indicate table access. A

separate copy of definer-rights package sales is installed in each regions schema.

The application package sales must have the privileges to access SALES_TAB for each region. One

way to achieve this is to write sales as a definer-rights package, and then install a separate copy in

each regions schema. In this case, the technique of code replication solves the access-rights problem,

at the cost of reduced maintainability.

Definers Rights -> Explicit Grants and Dynamic SQL

Alternatively, an application designer may choose to install a single copy of definer-rights package

sales in a central schema called COMPANY(see figure below). This requires two additional steps:

= Each region must grant access on table SALES_TAB to schema COMPANY.= Sales must be extended (to a new version sales+), to take its calling context into account, i.e., each

invocation ofsales must identify its region invoking it, and update SALES_TAB in that region. The

calling context may be passed in, to sales+, as an extra argument whose accuracy sales+ must be

able to verify.


17/25


March 1999

17

Figure 2. Sales database with a single copy of extended definer-rights packagesales+ in schema COMPANY. This implementation requires each REGION to grant

access on SALES_TAB to COMPANY.

Invokers Rights -> Automatic Calling Context Inheritance

Ifsales is implemented as an invoker-rights package, each invocation ofsales inherits privileges and

name-resolution context from the user calling it (see figure below). In other words, if REGION1

invokes sales, each SQL operation (query, DDL or DML) in sales behaves as though REGION1

executes it. Access to SALES_TAB resolves to the table in REGION1, and is tested against user

REGION1s rights.

Figure 3. Sales database with a single copy of invoker-rights package sales in

schema COMPANY. Each invocation of sales inherits the privileges of its callerand executes in the schema of its caller.

A Usage Tip For Invoker-Rights Programs

The application developer must be aware that any invoker-rights program that a user executes will

inherit all the privileges of the user, and can do anything that the user is able to do. Therefore, the

user must only execute such a program if the user trusts that it will not do something malicious.


18/25


March 1999

18

SQL QUERIES ON A LOCAL VARIABLE OF A NESTED TABLE OR VARRAY TYPE

In releases prior to Oracle8i PL/SQL Release 8.0, queries may be performed only against database

tables. Starting with Oracle8i PL/SQL Release 8.1, Oracle provides support for SQL queries on local

variables of nested table or varray types. In other words, users can now specify a PL/SQL local

variable or parameter of a nested table or varray type, in the FROM clause of a SQL query. In Release

8.0, the syntax for doing this was somewhat clumsy and involved the use of the THE operator, which

Oracle plans to deprecate in a future release. In Release 8.1, a new, much improved syntax is now

available through the use of the TABLE() operator. This feature provides a powerful way of querying

dynamically created in-memory data.

The following example demonstrates this ability:

CREATE TYPE nt_vc2_20 AS TABLE OF VARCHAR2(20);

CREATE TABLE t_vc2 (a VARCHAR2(20));

DECLARE

lvnt nt_vc2_20 := nt_vc2_20(NULL);

BEGIN

lvnt(1) := 'ONE'; lvnt.extend;

lvnt(2) := 'TEN'; lvnt.extend;

lvnt(3) := 'HUNDRED';

-- syntax available starting with 8.1

INSERT INTO t_vc2

SELECT cast_lvnt.COLUMN_VALUE

FROM TABLE(CAST(lvnt AS NT_VC2_20)) cast_lvnt;


19/25


March 1999

19

-- syntax available starting with 8.0:

INSERT INTO t_vc2

SELECT cast_lvnt.COLUMN_VALUE

FROM THE(SELECT (CAST(lvnt AS NT_VC2_20))

FROM dual) cast_lvnt;

END;

/

Note that this feature is currently available only with nested table types and varray types but not

with PL/SQL index-by table types.

USER-DEFINED OPERATORS

In Oracle8i Release 8.1, users may define schema-level operators and bind them to PL/SQL functions.

These operators may subsequently be used in SQL statements wherever a SQL built-in operator is

allowed. Furthermore, one or more user-defined index types may optionally support an operator.

This means that an index of this index type can be used in efficiently evaluating these operators.

This feature is very important for specialized datatype developers. For example, Oracle's ConText

datatype has implemented CONTAINS as a user-defined operator.

STATIC M ETHODS

Oracle8i PL/SQL Release 8.1 now supports the ability to define static methods, i.e., those that do not

have SELF as a parameter. Static methods are very useful in applications, since static methods that

logically belong to the object type, but do not operate on the SELF parameter, may now be packaged

in the object type itself.


20/25


March 1999

20

INTEROPERABILITY WITH C, JAVA

The Oracle8 Server, Release 8.0 provides the ability to call, from PL/SQL stored procedures, C

external procedures executing in separate processes. Oracle8i PL/SQL, Release 8.1 additionally

provides the ability to call Java stored procedures executing in the server.

LANGUAGE ENHANCEMENTS COMMON TO CALLING BOTH JAVA AND CPROGRAMS FROM PL/SQL

In Oracle8 Release 8.0, an application programmer was allowed to declare a procedure as

EXTERNAL (implemented in C) only where a PL/SQL procedure, or function body is considered

legal. This meant that an application developer could not declare an EXTERNAL procedure inside a

package (or type) specification. Oracle8i PL/SQL Release 8.1 introduces Call-Specifications, a

language extension that makes it much easier to call C procedures or Java methods from PL/SQL

procedures in the following ways:

= The application programmer now has the option of providing the CALL-specification, either in aPL/SQL package (or type) specification, or in a PL/SQL package (or type) body.

= This new syntax allows an application developer to specify mappings from PL/SQL procedures toprocedures and methods in other languages (such as C and Java), consistently across these other

languages.

= CALL-Specifications for C and Java procedures may coexist within a single PL/SQL package or typespecification, and may be called from either SQL or PL/SQL.

Here is an example of two CALL-Specifications (one for C and one for Java) in a single

package specification:

CREATE OR REPLACE PACKAGE call_spec_pack IS

PROCEDURE c_call (var1 NUMBER) IS

LANGUAGE C

LIBRARY some_c_library

NAME "c_call"


21/25


March 1999

21

PARAMETERS(var1 OCINUMBER, var1 INDICATOR SHORT);

PROCEDURE java_call(var1 NUMBER) IS

LANGUAGE JAVA

NAME 'java_call_class.java_call(oracle.sql.NUMBER)';

END call_spec_pack;

ENHA NCEMENTS SPECIFIC TO CALLING C PROGRAMS

In Oracle8i PL/SQL Release 8.1, it is now much easier to call C programs from PL/SQL procedures:

= Complete support for Oracle8 objects and collections types: Oracle8 objects and collection types may nowbe passed to the external procedure. New objects and collections may be returned from the external

procedure as IN/OUT, OUT, and RETURN arguments.

= Support for additional mappings: PL/SQL type NUMBER to C type OCINumber; PL/SQL typeDATE to C type OCIDate; PL/SQL types VARCHAR2, LONG and CHAR to OCIString; PL/SQL

types RAW and LONG RAW to C type OCIRaw.

= Caching of D LLs for improved external procedure performance: Oracle8i external procedures transparentlycache up to ten DLLs in a session. Subsequent calls to a C function in a cached DLL will not cause

the DLL to be reloaded, thereby significantly improving external procedure performance.

= Support for Pro*C to execute SQL callbacks into the database: Prior to Release 8.1, external procedurescould call back into the database only through OCI. In release 8.1, external procedures now support

Pro*C to callback into the database. Writing Pro*C to execute external procedures SQL callbacks is

substantially easier than writing OCI8 callbacks.

Here is a simple example of a Pro*C callback:

void UpdateEmp (with_context, empnumber, empnumberind)

OCIExtProcContext *with_context;

OCINumber *empnumber;

short empnumberind;

{


22/25


March 1999

22

exec sql register connect using :with_context;

exec sql

update emp set empno = 999

where empno = :empnumber:empnumberind;

....

....

}

INTEROPERABILITY WITH JAVA IN THE SERVER

Oracle8i provides strong support for Java in all tiers, including Java stored procedures, with a Java

Virtual Machine (VM) executing in the server. Oracle8i PL/SQL and Java interoperate seamlessly

and complement each other in the database. Consistent with Oracles theme of language

transparency, Oracle addresses PL/SQL and Java interoperability in two ways:

= A pplication level interoperabili ty: PL/SQL and SQL can call Java methods by registering callspecifications for the Java class. Java can also call PL/SQL and SQL, either through the JDBCinterface or through the use of SQLJ. In the future, Oracle plans to allow PL/SQL and Java stored

procedures in the server to be debugged transparently.

= Shared services between the Java and PL/SQL execution engines: Within the server, the Java VirtualMachine and the PL/SQL engine already share a number of common services, to provide users with

optimal performance and scalability.

For more details, please refer to [5], an Oracle technical white paper on Multi-Language Program

Development in Oracle8i.


23/25


March 1999

23

TOOLS FOR APPLICATION DEVELOPMENT

The Probe family of APIs provides a broad range of low level services that can help tools builders

build development environments to debug and monitor PL/SQL applications. The first of these

APIs was the debugger API, which has been available since PL/SQL Release 2.3.4. The Oracle

Procedure Builder product integrates with this, to provide a PL/SQL debugger.

New APIs have been added to Oracle8i PL/SQL Release 8.1, to support PL/SQL profiling, code

coverage, and profiling. These APIs are being made available to tools vendors.

PL/SQL AN D THE INTERNET

For information on how to use the PL/SQL cartridge with the Oracle Application Server to develop

Web applications using PL/SQL, please refer to [4], an Oracle technical white paper on Developing

Web Applications Using PL/SQL.

SUMMARY

Oracle8i PL/SQL Release 8.1 includes many features that improve ease of use and application

development. In addition, this new release includes a number of performance improvements. For

details, please refer to [3], an Oracle technical white paper on Techniques for Tuning PL/SQL

Applications. For more details on all the new functionality, please refer to [7] Oracle8i

Application Developers Guide - Fundamentals, Release 8.1.5, [8] Oracle8i Concepts, Release

8.1.5, and [9] PL/SQL Users Guide and Reference, Release 8.1.5. Oracle intends to fully support,

enhance, and extend PL/SQL, to make it even easier to use, perform even faster, and, in general,

much better.


24/25


March 1999

24

ACKNOWLEDGEMENTS

The authors of this paper, Usha Sangam (editor), Guhan Viswanathan, Dave Alpern, Kannan

Muthukkaruppan, Neil Le, Ron Decker, Radhakrishna Hari and Chandrasekharan Iyer thank Shirish

Puranik and Ashok Swaminathan for their review comments and suggestions for improvements to

this paper.

REFERENCES

1. Oracle8i PL/SQL - New Features and Future Directions - an Oracle Technical White Paper,

February 1999

2. Native Dynamic SQL: A Better Alternative to DBMS_SQL - an Oracle Technical White Paper,

January 1999

3. Techniques for Tuning PL/SQL Applications - an Oracle Technical White Paper, November 1998

4. Developing Web Applications Using PL/SQL - an Oracle Technical White Paper, January 1999

5. Multi-Language Application Development in Oracle8i - an Oracle Technical White Paper,

January 1999

6. Oracle8 Application Developers Guide, Release 8.0

7. Oracle8i Application Developers Guide - Fundamentals, Release 8.1.5

8. Oracle8i Concepts, Release 8.1.5

9. PL/SQL Users Guide and Reference, Release 8.1.5


25/25

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065U.S.A.

Worldwide Inquiries:

+1.650.506.7000

Fax +1.650.506.7200

http:// ww w.oracle.com/

Copyright Oracle Corporation 1999

All Rights Reserved

This document is provided for informational purposes only, and

the information herein is subject to change without notice.

Please report any errors herein to Oracle Corporation. Oracle

Corporation does not provide any warrant ies covering and

specifically disclaims any liability in connection w ith t his

document.

Oracle is a registered trademark, and Oracle8i, Oracle8, PL/SQL,

and Oracle Expert are t rademarks or registered trademarks of

Oracle Corporation. All other company and product names

mentioned are used for identi fication purposes only and may be

trademarks of their respective owners.

Documents

o8i plsql app dev twp