Oracle released the first generation of its front-end development tools with version 5.0 of its RDBMS. These products were known as SQL*Forms 2.0 and RPT. Although these tools are primitive by today's standards, they were a great advance for developers
of applications to access this powerful database management system. As more features were added to the RDBMS through versions 5.1, 6.0, 7.0, 7.1, and now Oracle 7.2, the front-end tools also evolved into the product that is now called Oracle
Developer/2000.
Developer/2000 primarily consists of three distinct products: Oracle Forms 4.5, Oracle Reports 2.5, and Oracle Graphics 2.5. These products can all be used individually or as an integrated application development platform. Although each has a separate
purpose, there are many similarities that enable you to create consistent and powerful applications.
Oracle Forms 4.5 is a tool that you can use to enter, access, change, or delete data from an Oracle database in a form-based environment. Unlike conventional third-generation programming languages, the developer does not write a program that presents
and manipulates the data. Instead, you build an Oracle Forms application by creating on-screen objects that are containers representing the data elements in the database. You then place these objects on the form with a graphical layout editor.
Based on selected activities called events, you can write triggers and program units to define the process to be executed whenever the event occurs. Oracle Forms 4.5 utilizes the concepts of object-oriented programming (OOP) with object inheritance,
reusability, and encapsulation, as well as modularity and polymorphism. These features enable the developer to construct high-quality, mission-critical applications in a very short time.
Oracle Reports 2.5 is used primarily to produce reports from data in the Oracle database. You, as the developer, can construct a report in the designer with a structured WYSIWYG ("what you see is what you get") layout editor based on a data
model that you create. You build this data model using the data model editor by defining a related set of database queries and break levels.
You can include procedural constructs to provide additional functionality for data formatting and display filters. Additionally, this tool provides several useful functions that can be utilized to calculate summary information (such as totals or
averages) at the various break levels. You can also use Oracle Reports 2.5 to execute database maintenance functions, although better tools can usually be found to perform these tasks.
Oracle Graphics 2.5 is used to graphically display Oracle data in a chart. These charts can be any of several types (for example, pie or bar charts) and are based on the data returned from a query. Although Oracle Graphics will produce these charts in a
stand-alone mode, the true power of this tools is as an OLE 2 server application that can be incorporated into OLE container applications such as Visual Basic, Excel, and, of course, Oracle Forms and Oracle Reports.
The Oracle Developer/2000 tool set requires a lot of resources! The version that runs on an IBM-compatible Windows 3.x PC requires at least 16 MB of RAM, with an additional permanent swap file of at least 8 MB to design any new application
modules. (It is possible to run most Oracle Developer/2000 applications on a smaller machine, however highly complex modules will still perform poorly on a lesser system.) To load all of the tools with demos and on-line documentation requires nearly 200 MB
of hard disk storage. This does not include Windows, DOS, or any other software, not to mention the applications that you need to develop.
With there is an abundance of tools available that interface with Oracle databases (such as Power Objects, PowerBuilder, Visual Basic, and so on), why should you choose to use Developer/2000?
When you work with small tables with very few joins, a less powerful, easier-to-use tool might be acceptable. However, if application performance is a critical factor, the Oracle Developer/2000 tools provide, by far, the best mechanisms for performance
tuning.
Oracle Forms provides several mechanisms that help ensure that an application provides consistently reliable data maintenance and presentation. With a few lines of code, (or in some cases, by selecting appropriate object properties), you can construct a
module based on several related tables with applicable propagation of changes whenever maintenance occurs. You can use these master-detail constructs to ensure that data integrity is preserved throughout the application.
Another very important concept that is "automatic" in Oracle Forms is row-level data locking. This ensures that more than one user cannot update the data at the same time and prevents arbitrary changes from occurring. These seemingly minor
features are the essential ingredients necessary for enterprise-wide database systems.
The Power Objects tool (also produced by Oracle Corporation) is powerful enough to be used for many query-only applications or for small single-table maintenance applications. This tool is syntactically compatible with Visual Basic and therefore is easy
to use. However, in order to build a menu-driven integrated application with the complexity necessary for enterprise-wide data processing, Power Objects falls short. Additionally, you must explicitly code data locking and master-detail propagation to
ensure proper integrity.
Visual Basic (a Microsoft product) can access Oracle databases using ODBC connectivity. Visual Basic has an advantage over Oracle Forms based on the fact that it is a more mature product and therefore offers the availability of many more add-on
components. The primary disadvantage of Visual Basic is its lack of support for data integrity issues.
PowerBuilder (produced by Powersoft) has several features that are not found in the Oracle tools. The most significant of these is its capability to provide queries that can be defined dynamically at runtime. However, PowerBuilder has been written to
support the Watcom SQL database engine and therefore lacks direct support for Oracle's data integrity. Another disadvantage of PowerBuilder is the fact that, in most cases, significantly fewer lines of code must be written using Developer/2000 when
accessing an Oracle database.
What truly sets Developer/2000 ahead of the other development products for Oracle databases are its features. These features enable the knowledgeable developer to rapidly deliver powerful, complex application units that can serve the diverse needs of
the users of an enterprise database system.
All of the development tools provide a similar point-and-click interface for constructing application components. This interface follows standard Windows-compliant conventions to ensure ease-of-use. By manipulating a mouse cursor, the developer can
select, copy, move, and delete the elements that combine to make up an individual module. The primary common elements of this interface are
As objects are added to a unit, the Developer/2000 tools utilize intelligent defaulting to define the properties of the object based on the context in which it is used. This feature enables the developer to construct simple default modules with
practically no programming. In many cases, routine database table maintenance can be performed according to predefined general rules and therefore do not require any special programming.
If you want to develop modules that do not operate according to the generalized defaults, Oracle Developer/2000 provides a feature called User Extensibility. This feature enables you to write procedural program code (using PL/SQL) to override the
default operation of Oracle Forms applications. These program units and triggers can be used for data validation, secondary data retrieval, or transactional control, to name just a few of the uses of this feature.
In today's ever-changing environment of corporate and MIS right-sizing, Developer/2000 (like all prior Oracle front-end tools) features the capability to run on a vast array of computer platforms. Portability enables you to write and test
applications on one platform and then "port" them to another system without any programming changes. Many organizations construct systems on stand-alone or networked PCs and then migrate them to an enterprise UNIX or mainframe computer. Except
for minimal user interface changes, the entire migration should not require any code modifications, which enables MIS departments to free themselves from lifetime commitments to obsolescing computer environments.
Another feature of Developer/2000 is that all of its components have been designed to be integrated. A complete database system requires the capability to display and maintain data in an on-line environment accessed by many diverse users. Many times,
users need reports that summarize information not available on-screen or need to provide a tremendous amount of detail that would not be practical in an on-line mode. Additionally, users sometimes need hard-copy reports for external customers or vendors.
Finally, graphical displays of data help users understand the information as it is presented. Through the use of menus, module tie-ins, and other functionality, Developer/2000 is a complete database management tool.
Finally, the Developer/2000 tools can be used with non-Oracle data sources. This feature is especially useful in an environment in which users can access data from a variety of sources. The Developer/2000 tools can be used to migrate data from a legacy
(for example, DB2) database to the Oracle database. The Oracle tools can also access normal text files directly using some of the interface functions that have been provided.
In order to provide a consistent development environment, several elements of the Developer/2000 tools are universal to all three tools. By learning how to use the function within one tool, you will understand how to use it in the others.
The Object Navigator, shown in Figure 31.1, is used to present an interface to the hierarchical structure of all opened application units. The example shown is for a new Oracle Forms 4.5 module; however, all of the Developer/2000 tools use a similar
Object Navigator interface.
Figure 31.1. The Object Navigator.
Within the Object Navigator window, the structure of all open units is displayed in either the Ownership View (shown in the figure) or the Visual View. The Ownership View displays the object structured according to the block (representing records from a
single table or view) where each is found. The Visual View, on the other hand, displays objects structured according to where they appear on the end-user screen. The developer can use the Navigator menu item to select the view that he desires based on his
own personal preference. Each item in the displayed structure can be preceded with an expand (+) or contract (-) icon to inform the developer that further details can be displayed for the object. By moving the mouse cursor and clicking a highlighted icon,
the structure will expand to show the next lower level of detail or remove the lower level from the display, respectively.
Standard scroll bars are provided on the right and bottom of the Navigator to enable the developer to change the portion of the application structure that appears within the window. Buttons that close, minimize, and maximize windows have also been
included; they operate similar to those found in most windows applications.
Below the Navigator window title bar are two fields and two iconic buttons. The first field displays the currently selected item in a list box. (Note: The currently selected item is also highlighted in the Navigator window, but because it can be
"scrolled out" of the window, this field reinforces the selection.) The second field is the Find item. The developer can type in this box and press Return to automatically navigate to the entered item. The two iconic buttons (which look like
flashlights) are used to search for the item in the Find box in either the forward or reverse direction, respectively.
The last part of the Navigator to be discussed is the iconic button bar, which appears on the left side of the Navigator window. These buttons are used to perform tasks that can also usually be executed using menu picks or hot keys.
The first button appears as a partially open file folder and is used to open existing application units, which can be Forms modules, menus, or program unit libraries when used in Oracle Forms. The next button, which appears as a floppy disk, is used to
save the current module to either a file or the database.
The next two buttons, a traffic light representing go, and an insect-like creature, are used to run the application module and to toggle the debugger facility on or off, respectively. If the debug facility is on, the user will be able to trace program
execution and track changes to application variables when the application is run. Full details of using the debug facility are discussed in the next chapter.
The next series of buttons are cut, copy, paste, copy properties, and paste properties, respectively. The first three work like the corresponding Windows 3.1 functions, whereas the last two are used to copy the individual properties of one object to
another existing object of the same type.
The next set of buttons is used to add and delete objects within the navigator. Depending on the currently selected object in the navigator, the newly added item will be created using intelligent defaulting to rapidly create application functionality.
Intelligent defaulting refers to the fact that based on the context of the activity, the default properties of the items will reflect the type of item and the environment within which it is inserted.
The last set of iconic buttons are used to expand and contract the structure of the module. These buttons, in order, are expand item, contract item, expand all lower items, and contract all lower items.
One of the features of the Developer/2000 tools is that they can be used without connecting to an Oracle database. This enables you to work on an application unit while you are unable to connect to an Oracle database. However, to generate (compile) an
application unit or run the module, the developer/user must connect to the database using the dialog box shown in Figure 31.2.
Figure 31.2. Connecting to an Oracle database.
The first two fields in the Connect dialog box represent the user's user ID and password (Note: the password will appear as asterisks as it is typed in) and the third field is the database connectivity string. For local database access, this field can
be left empty; however, for remote database access this field is required. The definition for this field can be defined in the user's oracle.ini (for Windows 3.x) or corresponding file. The connectivity string should be provided by your system
administrator who will also set up your user ID and password.
All of the Developer/2000 components use a similar interface for loading existing application units into their respective Designer environments. Based on the tool in use, an initial option dialog box will be displayed for the user to select the location
(file system or database) and the module type of the application unit to be opened. If you choose to open the program unit from the database, a second dialog box will appear that displays all stored units of the requested type in the database. If, on the
other hand, you choose to open the application unit from the file system, the standard Windows 3.x Open dialog box will appear, enabling you to select the source drive, directory, and file that should be opened.
Oracle Developer/2000 consists of three distinct products: Oracle Forms 4.5 for on-line data maintenance and presentation, Oracle Reports 2.5 for large-volume data reporting or hard-copy report generation, and Oracle Graphics 2.5 for graphical
presentation of data. These products require substantial system resources, but due to their reliable handling of integrity and transactional issues, they are superior to most other products for diverse enterprise database needs.
Developer/2000 features a point-and-click interface so it is easy to use, intelligent defaulting, user extensibility, portability, integration, and the capability to access non-Oracle databases. These features are unique among the tools available that
access Oracle databases. Although some of these features might exist in other products, no other products feature all these attributes combined.
To facilitate ease-of-use between the three integrated tools, Oracle has provided several common functions such as the object navigator, database connectivity, and access to the individual application units. These units are similar between each of the
tools, so that the developer who learns to use one will automatically know how to use the others.
The next three chapters explore each of these tools individually and in depth. After explaining each tool separately, the last chapter of this section explains how to integrate these tools with each other and external applications to provide a seamless
application system for end users.
Although you will be looking at many advanced topics, it is not possible to fully dissect each and every option for every application component in this guide section. I have been working with the Oracle tools for over ten years, and I can honestly say that most of my abilities have not been learned from a guide. As far as I know, not a single major league baseball player has ever gotten where he was by reading how to play the game, but has done so by lots of dedicated practice and experience. Likewise, I hope that this section of the guide can impart to you enough knowledge that you can work out the rough spots and become an adept all-star Developer/2000 programmer. Most of what I know has been gained through experimentation and observing the techniques used by other Oracle professionals. Hopefully, my experience will assist you on the road to using these development tools.