Record Groups, Global Variables and Parameters Question

Record Groups, Global Variables and Parameters Question
--------
What should I be using Record Groups for ?
Answer
------
Structurally, a Record Group is similar to an in-memory
Oracle table in that it has a row/column framework and
columns with datatypes of NUMBER, CHAR, and DATE. Analogous
to how storing data in a table occupies space on the
physical media, storing data in a record group allocates (or
occupies) space in the user's current process memory. The
more columns and rows the record group contains, the more
memory it will occupy.
Since record groups do not currently have any record
buffering mechanism in Forms 4.5 akin to that offered by the
database block object, populating a record group from a
query should be done with caution. Using a query that
returns 10,000 records will allocate memory to fetch and
store all rows returned from the query.
In particular, record groups are not designed to be a
replacement for database tables while your applications is
running. They may be optimal for relatively small lists of
lookup values, or medium-sized data structures for
application record-keeping on the client side, and are
generally most effectively used where your application might
have required arrays.
Question
--------
When should I use globals vs parameters ?
Answer
------
There is no *one* right way to use either, but here are some
guidelines that might help you decide:
Datatype: Globals are on CHAR data
Parameters are NUMBER, CHAR, or DATE
Storage: Globals each take about 260 bytes, regardless of
length
Parameters take what they need.
Creation: Globals are created the first time they are
assigned.
Parameters must be named and typed at design time,
or alternately may be added to a parameter list at
runtime with the Add_Parameter() built-in.
Default: Globals must have a default value programmatically
Values assigned.
Parameters can be assigned a default value of the
proper datatype at design time.
Assignment: Globals are assigned directly thru PL/SQL
assignment with the bind variable notation
(:GLOBAL.GLOBAL_NAME), or indirectly with the
Copy() built-in.
Parameters in the default parameter list (those
created at design time) are assigned directly
thru PL/SQL with the bind variable notation
(:PARAMETER.PARAM_NAME), indirectly with the
Copy() built-in. If part of a parameter list is
not the default parameter list, then
the Set_Parameter_Attr() built-in is used. In
addition, parameters which are declared at
design time can be supplied with values on the
command line using the "PARAMNAME=Value" syntax.
Reference: Globals can be referenced directly with bind
variable notation, or indirectly with the
Name_In() built-in.
Parameters in the default parameter list may be
referenced directly with bind variable notation,
or indirectly with the Name_In() built-in. If
part of a parameter list which is not the default
parameter list, then the Get_Parameter_Attr()
built-in used.
Scope: Globals preserve their value for the entire duration
of the Runform session, unless explicitly
Erased. They are visible to all forms which get
called during the session. Any modification made in
a called form to a global variable is visible to any
calling form and all subsequent forms in the session.
Parameters are only visible to the form in which they
are declared, unless they are passed as part of a
parameter list. In this case they supply incoming
values for the form-level parameters declared for the
called form.
The value of the parameter in the calling form is
thus visible to the called form in this way. Any
modification made in a called form to a parameter is
not visible to calling form. The called form gets
"fed" a snapshot of the parameter values a they
existed at the moment of the Call_Form(), and works
with private copies of the values.
Documentation: Globals can be created anywhere in any
trigger. Unless a Forms developer is
disciplined and uses some sort of
methodology, globals variables can be very
hard to find and document.
Parameters exist as named object at the form
level, can have meaningful default values,
and can be documented with object comments
like any other forms object.
Question
--------
How do I pass a Record Group from Forms to Reports or
Graphics ?
Answer
------
A record group is passed to Reports or Graphics as a DATA
parameter. This DATA parameter is a special type of
parameter that gives a signal to the integration code to
substitute the contents of the record group whose name you
give for the results of the query named by the query name
you indicate. Simple example:
(1) In Oracle Reports V2.5 you create a report with a query:
Query Name: FOOBAR_QUERY
Query: SELECT DEPTNO, DNAME FROM DEPT
(2) In Forms you create a record group in your favorite way
such that it has two columns, one NUMBER and one CHAR,
then you populate that record group (still on the forms
side). Say the record group is called PETE, and has two
columns A and B:
DECLARE
f RecordGroup;
g GroupColumn;
BEGIN
f := CREATE_GROUP('Pete');
g := ADD_GROUP_COLUMN( f , 'A', NUMBER_COLUMN);
g := ADD_GROUP_COLUMN( f , 'B', CHAR_COLUMN, 20);
/*
** Then populate the group in your favorite way
*/
END;
(3) When you setup the parameter list that you'll pass from
forms to the other tool, you create a parameter named
'FOOBAR_QUERY' and give it the value of 'PETE'. Since
it is a DATA parameter, this pairing of 'FOOBAR_QUERY'
to 'PETE' tells the integration code what to do when it
starts up the other tool. Instead of running the select
statement that defines 'FOOBAR_QUERY' in Reports, the
values from the 'PETE' record group will be substituted
as if they *were* the result.
Question
--------
Can I access the contents of a record group within a user
exit ?
Answer
------
To access the contents of a record group within a user
exits, the values will first have to be placed within a
database block. At present, user exits do not have any
knowledge of the data structure of an Forms record
group.
With the advent of ORA_FFI it is likely that the need
for user exits will now diminish as you can make MS
Windows SDK and SLL function calls directly from PL/SQL.
You will thus still have access to the Record Group
values.