Re: For S.Muench Oracle Corporation

From: Steven P. Muench <smuench_at_oracle.com>
Date: 1995/07/12
Message-ID: <SMUENCH.95Jul12164720_at_doh.oracle.com>#1/1

THE PROBLEM (Read on...See "The Solution" Below)

---

In Forms 4.5, to respond to complaints from users of Forms 4.0 that loading, saving, and referencing objects from the database was way too slow, we drastically simplified our storage model to be able to take advantage of Oracle's array fetch capabilities. This lets us chunk in practically all of the form's definition, in one huge array fetch. For all intents and purposes, there is one main table (FRM45__OBJECT) that stores all information about forms objects now, and when these objects have nested objects inside of them, they point at each other. If you think about the type of information that a product like Forms must save with the form definition (either to an FMB file or to Forms 4.5's product-specific data dictionary tables) this includes things like:

(*) Compiled P-Code and Debugging Symbols to support smart

        incremental compilation of your large forms

(*) Language-independent representation of all user-visible

        strings in the form (menus, hints, widget labels, etc.) to
        support not only European languages, but multi-byte character
        sets, and even right-to-left character sets (try representing
        kanji characters in ASCII !)

(*) Boilerplate images

(*) Boilerplate shapes and drawings

(*) OLE Container default document content

(*) Arbitrary levels of inheritance and overriding via

        property classes

You start to see how much of the content of this table is necessarily in an unintelligible (as far as SQL goes) binary format whose structure may change at any time. Since we don't want people building applications that depend on this binary representation that is subject to change, we discourage any interpretation of the database-based (or file based, for that matter) representation.

THE SOLUTION

---

The Forms 4.5 Designer has a built-in documentation mechanism which is accessible from the {File} / {Administration} / {Forms Doc} menu pick. This will generate a hierarchically structured ASCII file in the working directory named <FORMNAME>.TXT that you can use/view/grep-through to inspect all of a form's properties, including inheritance and overriding. Also included, are the text of all your triggers and pl/sql program units for easy reference.

This .TXT file is a read-only file, and is not the same as the .FMT file format which is just a text representation of all the binary information in the FMB file which you can check-in to source control systems. The FMT file must be convertable back into an FMB file without losing any content. The .TXT file is for user-readable documentation.

Hope this helps.

--
.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,
  Steve Muench              Email: smuench_at_us.oracle.com
  Sr. Product Manager
  Tools Development
  Oracle Corporation

Received on Wed Jul 12 1995 - 00:00:00 CEST