DataCraft -> Publications -> Forms  3.0 Paper

by Bill Pribyl

Note from the author, September 2002: This paper is woefully out of date. I only keep it on this server because I people are still interested in this topic. Plus, it's good for a chuckle. And by the way, there is no more character-mode form of Developer unless you count using a text-based browser.

CLICK HERE for PDF slides of the presentation delivered to the Houston Oracle Users Group on this subject, on 18 Sep 96. The presentation contained some then-hot-off-the-press information not contained in the text below. However, if you missed the talk, or even if you didn't, the text below offers some background information you may find useful.

Copyright 1996-2002 DataCraft, Inc. All Rights Reserved. No part of this article may be reproduced in any fashion whatsoever without the express written consent of the author. A version of this article was published in the September 1996 Oracle Tech publication of the South Central (US) Oracle Users Group.

---

First off, as Douglas Adams would say, DON'T PANIC. Just because you've got 1500 FRM files in production, you don't have to crisis-manage an upgrade when you discover Forms 3.0 missing from the CD with version 7.3 of the server. You probably have more time than you think. Further, you might want to skip Forms 4.5 altogether (you skipped 4.0 and lived to tell about it, didn't you?). Read on…

Is it true that SQL*Forms no longer ships with the Oracle server? Yes it's true, after server version 7.2, SQL*Forms, Menu, and Reportwriter are no longer shipping, but they will still work. In fact, Oracle has pledged to continue regular support of these three products (minus enhancements, of course) until the end of 1996, and will offer some continuing level of support through the end of the millenium. As in December 31, 1999. You've got plenty of time to figure out whether you want to go to Forms 4.5, or wait for Developer release 2.0, or maybe consider migrating to a different architecture altogether (see below). There…feel better already?

What kind of "support" can I get on the old tools? Until the end of 1996, Oracle is continuing to fix critical bugs in Forms 3, Menu 5, and Reportwriter 1. Considering the maturity of these products, Oracle's internal programmers probably aren't very busy on them. Even after December 31, though, Oracle will still be on the hook to field questions, provide workarounds "if possible," and provide customers with migration path information. Their programmers don't have to do any bug fixes, BUT, in my opinion, that's unlikely to be a problem for most sites…you probably long ago learned to live with whatever quirks the tools have. Just prepare yourself to hear more than once the words "Why don't you upgrade to Developer/2000?" out of Oracle Tech Support.

But I'm running all host-based and want to run 7.3 of the server so I get all the cool new server features. You can. What you cannot do is install the old tools from the old distribution on top of 7.3 and then relink. But-and this is straight from Oracle, I didn't dream it up-you can set up a separate ORACLE_HOME directory, and there install only the tools from, say, the 7.2 distribution. Then just run two-task with the 7.2 tools as clients against the 7.3 server.

What is "two-task" and how do I do it? Two-task is like running client and server on the same machine. On Unix you set the TWO_TASK environment variable to the SQL*Net 2.x name of the database, such as PROD.ACME.COM. You'll have to use Net 2.x on both the 7.2 tools side and the 7.3 server side, though, since 7.3 does not include SQL*Net 1.x. Set your ORACLE_HOME to be the 7.2 installation. Then, every time you invoke a tool such as Plus, Forms, Menu, or Reports, you'll be using 7.2 executables against the 7.3 server. This configuration is supported by Oracle.

So what's the down side to hanging on to Forms 3.0? The biggest problem that I see with this two-task approach has to do with operating system support for Oracle 7.2 client tools and later versions of Oracle server. As time goes on, your operating system vendor may desupport the O/S version required for Oracle 7.2 client tools; or you may require a later O/S version to run Oracle 7.3 (or whatever is going to come after that). So while you may be able to get some kind of support for Forms 3.0 until the end of the millenium, you may not be able to get support for the required O/S to run it on. You can judge for yourself how large a risk this is.

Shouldn't we start to move away from host-based applications and into the "client-server" world? Maybe, maybe not. A lot of users just can't afford to convert to put a PC on every desktop, or they can't afford the memory upgrades required, at least not all in one fiscal year. That's one reason Oracle offers host-based character-mode versions of the Developer/2000 runtime tools, at least for Unix. Run your old forms through Oracle's new 4.5 generator, and out the other end you get the new ".fmx" Forms runtime files that look and feel virtually identical to Forms 3.0, other than the key mappings, which you should be able to make compatible. Ditto, I believe, for Menu and Reportwriter. Yeah, there are a few migration gotchas, but they're well documented and probably uncommon in most code. Besides, hint, hint, you might want to skip the current client-server chapter in computing history.

So we can just migrate to character-mode Developer/2000 Forms & Reports? Yes, that approach has certain benefits. Migration costs could be kept low. You can stay version- and full support-current. Keep in mind that your developers will need souped-up, 32+ meg RAM PCs (or X terminals) to maintain the applications, since there are no character-mode incarnations of the "Designer"-type tools. Really, that's not a bad thing, since the new GUI developer's interface is vastly improved and should make developers more productive anyway. One more thing: I heard, but later determined false, a report that Oracle plans to discontinue character-mode tools; in fact, an excellent source within Oracle recently asserted that character mode will exist as long as the Developer/2000 tools are supported on Unix-type environments. Considering the enormous number of SQL*Forms 3.0 applications out there, it will probably be a very long time before Oracle considers dropping Unix versions of their Developer/2000 tools.

What is your opinion of third-party "GUI" converters? There is only one such product that I've heard of, and I have yet to recommend it, for three major reasons. First, performing an intelligent migration from character-mode to a well-designed graphical user interface is something that will require re-engineering your application. Making a good GUI application is not the same thing as making a good character-mode app. Second, the (unnamed) vendor's licensing costs are, in my opinion, exhorbitant; the price of the converter is on a per-megabyte of INP file basis, and is almost more expensive than converting by hand. Moreover, they apparently make no accommodation for running a 3.0 Form through the converter more than once, say, if you want to start over. Finally, running Forms through a converter will present few if any training or educational experiences to your current staff.

What else should we do? Start thinking outside the box. Do you really want all the headaches associated with desktop machines running Windows-based client server applications? All the GPFs, DLL version incompatibilities, upgrade nightmares, poor remote troubleshooting facilities, and end-user "why CAN'T I run Flight Simulator in the background" crises? If I were the manager of a large MIS shop, I'd give serious thought to wading into the coming wave of Intranet-style application development, where the end-user interface is a common web browser, and all applications are written in a way that users need only the browser and a password to create, query, report on, & print data. Toss in some extra benefits like ease of use, ease of administration (especially if you run your apps on a network computer instead of a PC), enormous cost savings, extra capabilities like integrated multimedia & email, and it is easy to see why many believe that conventional client-server is virtually passé.

Is it really client/server, or just Developer/2000 you don't like? Developer/2000 has a definite place. Despite its large footprint, high cost, and steep learning curve, it can be one of the fastest means of building database applications, particularly for an all-Oracle shop. Moreover, when combined with Designer/2000 in the hands of someone who knows what they're doing, application development can be very efficient indeed. But try telling a company with 10,000 desktops that they have to upgrade them all from 8 to 16 or more megabytes of RAM, not to mention the challenges of ongoing software upgrades. Don't give up, though; a coming alternative sounds like a solution to many of these prayers, at least in in theory. Oracle in July announced that Forms, Reports, and Graphics will be able to run on a server, in a manner that is accessible to web browser clients. Oracle Developer/2000 tools will achieve this magic in Release 2.0 by generating a Java applet at the same time as they generate the runtime binary. The end user will be able to invoke his or her favorite web browser, and download the applet on demand-instant Intranet. It's too early to tell whether this will be an efficient architecture, but it should certainly offer Oracle users a seductive upgrade path. It's somewhere in the future, and there are third-party alternatives today, but it is definitely something to watch.

OK, maybe you've convinced me to look at Intranet upgrade paths out of Forms 3. How will Oracle tools will help us move towards Intranets? More ways than I can count. In a single day in July, Oracle issued nine different press releases on their Intranet strategy. The WebServer, mentioned elsewhere, is just the beginning. There's also a significant commitment to being able to generate web-based applications from within Designer/2000. That is, instead of generating Forms & Reports, you press a different button & get HTML pages, complete with all the hooks to get to Oracle server data. At press time, generation facilities existed for read-access only, with Oracle promising insert/update/delete later in 1996. There's also a thing called Oracle Web Request Broker that, among other things, will be able to securely preserve login state between successive server requests from the same user (this turns out to be a big deal, by the way). As I hinted before, reports will be executable on a server, and dynamically downloaded to the browser, in HTML or Adobe PDF, on demand. Charts will be produced on the fly in GIF or PICT format. Finally, Oracle already sells vertical web-enabled applications, and will separately sell streaming video and web/database text searching tools.

So, what's the bottom line for legacy Oracle shops? Don't rush to upgrade to client/server GUI. Look at character mode Developer/2000 as a possible interim, and consider alternative "thin client" architectures for the long term. Play your cards right, and you penny-pinching procrastinators can come off looking like visionaries. I recommend, if you haven't already done so, setting up a pilot Intranet project with a web server linked to a database server. One place to start is with Oracle's WebServer that ships bundled for free in Oracle 7.3. Ask your best programmers what kind of magic they can cook up with Java on the front end. Get them Internet access from the office so they can download Java compilers, tutorials, and sample Java code, since it is sure to play a significant role in Oracle's web-enabled future. If you've got Designer/2000, get the latest release, and see what it can do in this area. And most importantly, do not believe any "consultants" or other charlatans who tell you that you must upgrade to Forms 4.5 by the end of 1996. They are, to put it gently, uninformed.