Oracle Power Objects

• Oracle Corp., 500 Oracle Pkwy., Redwood City, CA 94065; 415-506-7000.
• Pricing: Standalone version, $395: client/ server version $1995.
• Minimum requirements: Windows environ- ment: 386 or higher, 4MB of RAM, and 25MB of hard-disk space (for full installation op- tion): Windows 3.1 or later recommended. Macintosh environment: 68020 or higher pro- cessor, or Power Macintosh computer with PowerPC 601 or higher processor, 12 MB of RAM 25 MB of hard-disk space (for full instal- lation option), System 7.0 or later, and the Apple Shared Library Manager 1.1.2 or later.

I must admit, I had a few doubts when I began this review of Oracle's Power Objects development tool. Initially, I ex- pected another Visual Basic/PowerBuild-er “wanna be” product. However, what I found was a very credible development environment that may one day, with a lit- tle more maturing, be a “best-of-class” front-end development tool. Power Ob- jects is Oracle's long-awaited attempt at a development environment targeted at the same marketplace that today is dominated by products such as Microsoft's Visual Basic and Powersoft's Power Builder.

Power Objects comes to the client/ server marketplace at an interesting time. With a recent upgrade to Visual Basic and Borland's Delhi gaining steady market-share, is the market ready for another 4GL development environment? Typically, when consulting with organizations in forming their technical architecture, I purposely warn against selecting “revision 1.0” (actually this is version 1.04) products as part of their toolset. However, Oracle has done a good job of incorporating a lot of positive features from the leading vendors today, along with a good measure of Oracle's own ingenuity, to create a product that isn't just another ho-hum 4GL tool. In addition, Power Objects is worthy of consideration for those shops that have both Windows and Macintosh environments, because the code is portable between the two platforms.

Out of the Box

The Power Objects forms painter lets you control the placement

and setting of properties, as well as create method code.

FIGURE 1

Power Objects come in two different flavors. The standalone edition includes access to the local Blaze database or, if purchased separately, Personal Oracle. The more expensive client/server version delivers additional native access support for Oracle 7.1, Microsoft SQL Server 6.0, and Sybase SQL Server 4.2.1 and System 10. This release of Power Objects does not support ODBC.

In this review, I worked with the client/server version. The installation from the CD-ROM allows for several different options, including loading of Power Objects samples, documentation, and OLE 2.0 DLL files. After selection all the options and completing the 10-minute install, my hard disk was 25MB lighter. The trend of including a local database, such as JET for Microsoft or Watcom SQL (now SQL Anywhere) for PowerBuilder, is also part of Power Objects strategy. The Blaze database included with Power Objects provides a small footprint (300K) local relational DBMS.

SQL Support

One would think that Oracle might have gotten more mileage out of incorporating its successful Personal Oracle product with Power Objects as the local DBMS. However, it looks like Oracle's use of Blaze was meant to appeal to both the memory-and disk space-”challenged” users. One drawback of this release of Blaze is that is doesn't support compound keys.

In looking at any client/server devel-opment tool, it is important to assess three key factors; development environment, data access, and component support. Let's start by reviewing the development environment.

Development Environment

Before the first-time Power Objects user begins exploring the development environment, a tour through the Oracle-supplied automated demo is a must. The demo automates the creation of a simple master-detail window. In addition, Power Objects ships with eight unique sample applications that do a great job of illustrating its features.

After entering Power Objects' design- time environment, all available application, session, and library objects are loaded for display as icons. Applications, displayed as folder icons, consist of components that make a deliverable unit. These components can be forms, reports, user-defined classes, and bitmaps. Sessions, displayed as network connector icons, are used to establish a connection to a data resource. Once connected, all DBMS objects to which the developer has access, including tables, views, and indexes, are displayed, along with connection information. Libraries, displayed as book icons, are used to organize globally accessed components such as bitmaps and classes.

Because everything really begins with

d

FIGURE 2

an application, I created a small one to track courseware royalties. Once you as- sign a name to the application, you can build one of several application compo- nents, such as a form or report. To build a new form for the royalties application, invoke the new form dialog from the tool- bar. (See Figure 1, page 29.) Placing components on the form is pretty standard fare. Select a control from the tool palette and drop it onto the form. Note the prop-erties dialog on the right hand side of Fig-ure 1 for the OK command button btn-ok.

The property and method (event) dia-log is probably the most visited area of any development tool. (Power Objects does not make the distinction between methods and events; instead, it refers to event, subroutine, and function code as methods.) All method code is written in Oracle Basic and looks almost identical to Visual Basic scripts. Power Objects has the most ingenious properties dialog in-terface I have seen as far. Both methods (events) and properties are displayed in the same list. The default is set to show methods and properties together, sorted alphabetically. However, via three options presented in the dialogs toolbar, you can tailor access to fit your needs.

One option allows properties such as “Enabled” and “Label” to show first, al-phabetically, followed by methods. Prop- erties are distinguished with a diamond to the left of their name, and methods are distinguished with a right pointer. The second option separates standard methods

and properties from user-defined ones. The third option provides a toggle to show or hide unused methods. As might be expected, you can combine all of these options for full customization.

Unfortunately, there is one glaring improvement that needs to be made, and that deals with adding method code. Let's say method code is added to the “click” event for the “OK” command button in Figure 1. By clicking on the method name presented in the properties box, you get only a small window in which to enter the script. To enlarge the editing area, you must manually resize the entire properties dialog box by dragging the borders - not fun. I also would have liked a horizontal scrollbar to make entry of property information easier.

Some annoying things I found in the development environment deal with simple things such as the lack of support for placing an “&” before a text label or control in the development environment to provide mnemonic keyboard features. Mnemonics are supported on menus only. Other areas of the programming environment that need increased functionality are menus, toolbars, and status line objects. These objects are all runtime objects, which means that they are built with Oracle Basic scripts and are generated dynamically every time the application executes - you never see them in the development environment. Power Objects makes it a little less painful by providing some standard default menu setups and quite a bit of sample code, but it still left me feeling empty. I wouldn't be surprised if the next release of Power Objects doesn't support static and visual menu, toolbar, and status line objects.

Database Access

Oracle has done a good job of building an easy-to-understand user interface for data access. Perhaps not to the level that Sybase/Powersoft has done with Power-Builder 4.0 and its DataWindow objects, but it's most certainly a more elegant ap-proach than Microsoft Visual Basic 4.0 data controls. In this review, I connected to the Blaza database locally on my client, and I had both Oracle NT 7.1 and Microsoft SQL Server 6.0 running on my server. Power Objects does not support ODBC in its current release, only native driver access.

Connecting to a Power Objects session displays all resources to

which the developer has access, including tables, views and indexes

Power objects funnels all data access through “a session.” The session object establishes a connection to a data resource and visually displays all objects that you have authority to access, such as tables, views, and indexes. Once you define a session, a connection to the DBMS can be made to display your authorized objects. Figure 2 shows and active connection be-tween Microsoft SQL Server 6.0 and my Windows NT server named “latte” (now you know one of my vices) and the infa- mous PUBS database. Notice that the different icons represent different objects such as the “authors” table, “titleview” view, and “pubind” index. I was also able to create a session object just as easily, talk to Oracle NT on the same Windows NT Server machine, and connect to the sample Employee database that ships with Oracle NT.

Once you define and establish a ses-sion, the real power of Power Objects' data access features becomes obvious. Ta-bles and views, or parts of them, can be dragged and dropped onto forms, creating bound record sources between session objects and Power Objects containers or controls. Record sources are like view-ports into data. Record sources are bound to containers in Power Objects, Containers can be embedded forms, forms, repeater displays, reports, and user-defined classes.

You can bind a control to a column of a record source. Almost all controls in Power Objects are bindable, including charts, list boxes, pop-up lists, and radio buttons. You can do all of this graphically by dragging and dropping record sources such as entire tables, portions or tables, or views directly onto either the container (form, report, and so on) or control (list box, combo box, and so on). By following this drag-and-drop metaphor, both the record source and record source session properties are set in the target object, along with the individual column and column attributes (data source and data type). If you drop a table or portion or a table onto a form, each column becomes a text field control bound to the table. You can then change the text field controls to different types of controls. In addition, if controls already exist on the form and are not yet bound to a table column, you can set up the link be dragging the column to the control.

Creating master-detail windows - once of the most common front-end designs found in client/server applications - takes nothing more than a few drags and drops. However, if you need more flexibility, another way to connect to database objects is through the SQL-LOOKUP function or with embedded SQL implemented in the EXEC SQL command. Both of these options allow complete customization of the SQL syntax, and they also provide access to back-end, server-specific features such as stored procedures.

Concurrency options are very robust in Power Objects, allowing locks to be toggled back and forth between optimistic (lock at the earliest point of access). Power Objects also lets you control buffer flushing to enhance failover integrity.

The last data access feature that was truly impressive was the upsizing strategy. I opened two sessions, one against the local products table provided in the samples stored in Blaze, and the other against Microsoft SQL Server PUBS database located on latte, the Windows NT Server machine. By dragging the Products table from the local Blaze connected session and dropping it on the remote SQL Server session, both the DDL schemas and the data were upsized. Double-clicking on the Products table on SQL Server 6.0 let me review and add/delete/update the upsized data.

Upsizing is a nice feature but can cause problems for the target server. Unless logging can be disabled, the console operator may have to swap log files. Due to a lack to properly set freespace parameters, you may also need to perform a subsequent reorganization of the target tables.

Some data access areas that I would like to see Power Objects improve upon deal with editing and execution of SQL statements, the table painter dialog, and ODBC access. Power Objects could really use a free-form SQL painter that lets you construct and execute SQL statements. Once tested, it would allow for the pasting of those statements into method code. Something similar to the database manager supplied in Power Builder 4.0 would be great. Actually, Oracle should look in its own backyard by taking the generic ODBC test application that ships with Oracle NT and molding it into Power Objects: it is an excellent applet that I can use regardless of my DBMS back end.

The table painter dialog is useless in its current form because it doesn't support compound key creation, regardless of the target DBMS. Power Objects has no problem dealing with compound keys programatically, but there is no way to define or alter a table that requires compound keys visually. Oracle assures me that this problem will be taken care of in the next release. ODBC seems to be a de facto standard in all development products today, but Power Objects won't be providing support until its next release.

Component Support

Component support is well integrated into the Power Objects development environment. You can load third-party OCXs into the environment for inclusion on the tool palette. Power Objects also provides for user-defined methods (subroutines and functions). Methods also support overloading or, in object-speak, polymorphism. Let's say you want two different “add” functions that do different things depending on the number of parameters or data types passed. Power Objects lets you create two functions called “add” and, based on the runtime examination of the calling parameters, it will call the appropriate function.

It seems like all of today's development tools boast object orientation, and Power Objects is no exception. Inheritance is supported for all visual components and forms within Poser Objects. This enables organizations to build reusable component code, control it in one place, and then have development teams work from standard templates. Both method code and property features let you override ancestor behaviors. As with the data-access interface, you can draft a class from one library or application to a target application, and the target application will inherit that class's properties and methods. The receiving application can then extend, modify, or even add new user-defined properties and methods to the inherited class.

The developer actually has two options when building the execution environment. This first is to create a runtime executable that creates a (.PO) file. This can then be invoked from the Power Objects runtime application (which would have to be distributed to all users). The second option is to build a standalone executable that creates an .exe file. Keep in mind that neither of these executables is true compiled code; they are really-code that is similar to that generated by other tools, such as PowerBuilder and Visual Basic. Power Objects does not support multi-tier application development or de-ployment, but it will let you port the finished application to the Macintosh and, in the near future, OS/2.

Power Objects is an excellent first cut at an enterprise development tool, build to compete head-to-head with the likes of PowerBuilder and Visual Basic. Power Objects' support of visual data access objects and its interfacing with containers and controls is very intuitive. I also like Oracle's properties dialog, which is easy to use, with the exception of the method-code edit window. Inheritance is also nice, especially as the industry moves toward reusing more and more components. However, Power Objects has some maturing to do. At times I found all of the open windows, which couldn't be minimized, difficult to keep tract of the position correctly for drag-and-drop operations. The lack of static menu, toolbar, and status line objects is also cumbersome. I also would have expected Oracle to have partnered with more vendors to provide more OCX's for the tool palette provided with the product.

If your organization is trying to stay as homogeneous as possible, Power Objects could be the ticket for an all-Oracle solution. Oracle certainly has both the financial and technical clout to grow Power Objects into a full-featured enterprise development tool. I eagerly await the next release to see if it meets that expectation.

*********

Paul Reed is president of Jackson-Reed Inc., a Seattle-based international training and consulting company focused on migrating organizations to client/server technology. You can reach Paul via the Internet at prred@jacksonreed.com or at http://www.halcyon.com/prreed/jackreed.html.