Figure 2-5. The programmer's user interface in Oracle Forms Builder

To help provide the kind of functionality that most users expect, Oracle provides an assortment of extensions to PL/SQL that are unique to the developer tools. For example, in Oracle Forms, PL/SQL programs can:

• Use on-screen item values as bind variables—for example, in a block named bk with a user-enterable field named isbn, the notation :bk.isbn would bind its value for the current record.

• Populate drop-down lists using data obtained from a database table.

• Automatically execute logic on end-user events such as clicking the mouse or navigating out of an input item.

• Control the appearance of the user interface, for example by displaying or hiding input items or windows.

Client-side PL/SQL can exist in one of three places in the application.

Triggers

These PL/SQL blocks fire on specific application events such as startup, mouse click, or data validation.

Program units inside a particular application

These are available to call from any other PL/SQL program in the same application.

A PL/SQL library of your own reusable client-side programs

You can call these from any client-side application.

And, of course, you can call server-side PL/SQL programs from inside these applications as well. However, there are a number of limitations in the way that Oracle has implemented these calls. For example, you can't use server-side package variables or cursors directly in a client-side program (you have to put a wrapper function around them instead).

2.3.1 Moving pl/sql Programs Between Client and Server

Moving PL/SQL code between the client and the server can be easy, but only if you haven't used any nonportable aspects of the language. For example, Figure 2-6 shows the result of doing a "drag and drop" of two stored packages from the database to a client-side PL/SQL library; the bodies didn't compile, as indicated by an asterisk. This reflects the fact that the packages use PL/SQL features that are not supported on the client side. One of the features is native dynamic SQL. To resolve this problem, I could eliminate the offending programs from the package body, or possibly convert the code to use the client-side EXEC_SQL built-in.

I had another problem with these packages: while the client-side PL/SQL engine can handle programmer-defined exceptions raised with the RAISE_APPLICATION_ERROR built-in on the server, client applications cannot themselves raise this exception. A workaround might involve centralizing your programmer-defined client exceptions in a client package specification.

Figure 2-6. The Object Navigator in Oracle Forms shows the result of dragging and dropping two packages from the server to the client

Often, PL/SQL developed for the client is not a good candidate to move to the server, because it is likely to contain many things that limit its portability. For example, if the code contains references to client-specific bind variables like :bks.isbn, or uses Oracle Forms-specific built-ins like SHOW_ALERT or EXECUTE_QUERY, it will fail to compile on the server.

If you are doing a lot of work with Oracle's client tools, you may want to get a copy of Oracle Developer Advanced Forms & Reports, by Peter Koletzke and Paul Dorsey. As its title indicates, though, it is not a "starter" book.